-
-
Notifications
You must be signed in to change notification settings - Fork 921
Comparing changes
Open a pull request
base repository: jruby/jruby
base: c9790ea19b97
head repository: jruby/jruby
compare: 2614c773b8f4
- 8 commits
- 8 files changed
- 2 contributors
Commits on Jan 14, 2018
-
Extract parseRegexpFlags to Lexer
And use the same function from both Ripper and main parser.
Configuration menu - View commit details
-
Copy full SHA for 0829a85 - Browse repository at this point
Copy the full SHA 0829a85View commit details -
Move Regexp checking from ParserSupport to Lexer
While not really related to Lexing, this is a component that is shared between Ripper and the main parser, and that seemed like the lesser evil.
Configuration menu - View commit details
-
Copy full SHA for 54a483b - Browse repository at this point
Copy the full SHA 54a483bView commit details -
Align validation code with MRI
It seems to have been `!ENCODING_IS_ASCII8BIT(str)` from the beginning, so I'm not sure why it was the opposite here.
Configuration menu - View commit details
-
Copy full SHA for 57661ef - Browse repository at this point
Copy the full SHA 57661efView commit details -
Make sure to clear $! when rescuing RaiseException
The code was copied from Parser support, so it was clearly broken before, but it had to be fixed now as parts of the Ripper test suite relies on $! rather than explicitly catching the exception.
Configuration menu - View commit details
-
Copy full SHA for a089f8a - Browse repository at this point
Copy the full SHA a089f8aView commit details -
Add support for validating Regexp in Ripper
This uses the fact that Regexp tokenization is handled by a single StringTerm, and thus all tSTRING_CONTENT fragments are easily collectable until the tREGEXP_END comes with the options that we need for validation. The validation itself is a copied/simplified version of what is performed by the main parser, as large parts the validation depended on the AST structure, which we do not have here. Technically, this doesn't perform the validation at the same point in time as the main parser, as it performs the validation when encountering the tREGEXP_END token rather than when processing the regexp rule. I speculate that the difference doesn't really matter given that the only thing we could do with the tREGEXP_END token is to apply the regexp rule.
Configuration menu - View commit details
-
Copy full SHA for 38d526b - Browse repository at this point
Copy the full SHA 38d526bView commit details -
Simplify the regexp validation logic
Use a separate variable to track whether things are dynamic or not, and use a List to avoid tracking the last element explicitly.
Configuration menu - View commit details
-
Copy full SHA for d3a8051 - Browse repository at this point
Copy the full SHA d3a8051View commit details -
Inline the regexp validation inside ParserSupport
The methods were only retained to provide the old interface, but by directly calling the new methods in the Lexer, we can remove the old methods, given that we don't really need to be backwards compatible here.
Configuration menu - View commit details
-
Copy full SHA for 836f80e - Browse repository at this point
Copy the full SHA 836f80eView commit details -
Merge pull request #4902 from grddev/ripper-regex
Add support for validating Regexp in Ripper
Configuration menu - View commit details
-
Copy full SHA for 2614c77 - Browse repository at this point
Copy the full SHA 2614c77View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff c9790ea19b97...2614c773b8f4