Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding tests that verify that jruby-1067 works as expected - ie Strin… #3761

Closed
wants to merge 4 commits into from

Conversation

jstemen
Copy link

@jstemen jstemen commented Mar 27, 2016

It looks like jruby-1067 has already been fixed. These tests show that capturing by named parameters with StringScanner#scan works.

@kares
Copy link
Member

kares commented Mar 29, 2016

// cc @eregon does it look 👍 to you?

@jstemen
Copy link
Author

jstemen commented Apr 14, 2016

Hmm... It looks like the tests are failing because they are using the truffle.mspec config. I didn't see that documented in the BUILDING.md file. The "-X+T" flag on line 16 seems to be what is causing the failure. Can anyone point me towards some documentation about what this flag does? Thanks

@nirvdrum
Copy link
Contributor

"-X+T" enables the Truffle backend for JRuby. The Travis target failing is running the specs on the Truffle backend, so the presence of the flag is appropriate. More than likely, the new specs demonstrate a bug in the Truffle backend that we'll need to deal with. In the meanwhile, I think it's appropriate to just simply tag those specs.

Those tags live in spec/truffle/tags. But I think you could also just merge this and we can tag once in master.

@jstemen
Copy link
Author

jstemen commented Apr 20, 2016

@nirvdrum , thanks for the info. I added the tag in to ignore the test for Truffle. The appveyor/pr build is failing now, but I'm not sure if that's related to my change.

@enebo enebo added this to the Invalid or Duplicate milestone May 21, 2024
@enebo
Copy link
Member

enebo commented May 21, 2024

This is very old now and it is a shame if these specs did not make it into ruby/spec but if there is still interest these should get added as a PR to ruby/spec. If this was clean to merge I might just land it and it would make it upstream but as it stands it should just become a ruby/spec PR. Very sorry this never got merged.

@enebo enebo closed this May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants