[pull] master from whitequark:master #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…l variables (#813) Closes #812. This commit tracks upstream commit ruby/ruby@fa87f72.
#816) Closes #815. This commit tracks upstream commit ruby/ruby@ecb6d6a
Firstly, this fixes an issue with non-interpolating squiggly heredocs, where line continuation characters should be ignored. Two things were broken: - The line continuation backslash would be removed, as well as the subsequent carriage return - The subsequent line would not be dedented. For example, the following source: ```ruby <<~'END' foo \ bar END ``` Would be parsed as follows: ``` (dstr (str "foo ") (str " bar\n")) ``` With the change, the result is: ``` (dstr (str "foo \\\n") (str "bar\n")) ``` This also fixes an issue with interpolating squiggly heredocs, where an escaped backslash followed by a newline would be interpreted as a line continuation. This is issue #789. In that case, the following source: ```ruby <<~END foo \\ bar END ``` Would (again) be parsed as follows: ``` (dstr (str "foo ") (str " bar\n")) ``` With the change, the result is: ``` (dstr (str "foo \\\n") (str "bar\n")) ```
This fixes an issue where beginless ranges at the start of a line would be interpreted as continuing an expression starting on the previous line. Unlike leading dots for method calls, `..` and `...` at the start of a line do not continue an expression from the previous line.
This commit tracks upstream commits ruby/ruby@37eb5e7 and ruby/ruby@9f3888d.
…#828) This commit tracks upstream commit ruby/ruby@11ae581.
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
…constants (#1064) A constant always start in uppercase but a local will not always start with lowercase. `_foo` and `💎` are both valid local variables.
It's a bit awkward: rubocop and rubocop-ast use this list to generate visitors and node type predicates. Since they both use this, it doesn't make much sense to add this handling in rubocop I think. On the other hand, adding this to prism doesn't really work since the parser there is lazily loaded, and by rubocop as well since users may just use older ruby versions. Prism itself has no dependecy on parser to eagerly add to this list. I think adding this to parser is ok, and is also the simplest solution to the problem. The list can (and does) contain entries that are parser-version specific, this just extends that policy a bit farther than it used to be.
Follow-up to rubocop/rubocop-ast#365 (comment) "implicit `it` parameter" doesn't seem to be a commonly used term. Use "`it` block parameter" instead.
These Rubies have been released. - https://www.ruby-lang.org/en/news/2025/03/26/ruby-3-2-8-released/ - https://www.ruby-lang.org/en/news/2025/03/26/ruby-3-1-7-released/ ## Ruby 3.2 branch Bump 3.2 branch from 3.2.7 to 3.2.8 ruby/ruby@v3_2_7...v3_2_8 There seems to be no change to syntax. ## Ruby 3.1 branch Bump 3.1 branch from 3.1.6 to 3.1.7 ruby/ruby@v3_1_6...v3_1_7 There seems to be no change to syntax.
The following is how different versions behave:
```
# Valid only in 2.7
case 0; in _1; end
1.then { 1 in _1 }
# Valid in no versions
case 0; in ^_1; end
# Valid an all versions
1.then { 1 in ^_1 }
```
`@builder.accessible` makes the numparam visible to the environment,
so it must be called first
* Supress warnings during regexp creation
User input can contain arbitrary regexes.
Something like `Parser::CurrentRuby.parse("/[\177\01\1778]/")` shows a warning:
> character class has duplicated range: /[\x7f\x01\x7f8]/
* Don't emit warnings when parsing floats
`Parser::CurrentRuby.parse("9.99
8000
99e999")`
> Float 9.9999e999 out of range
…t block (#1049) Upstream commit ruby/ruby@a850cd1 is specific to 3.3, previous versions already did not allow this. See https://bugs.ruby-lang.org/issues/20392 for a bit more info. But since the super node has has a different shape, it behaved unexpectedly in earlier ruby versions already. It allowed forwarding with zero and one arguments and failed for more. Now correctly rejects it as invalid syntax, except in Ruby 3.3, that fix has not been backported.
…nts (#1051) Starting from Ruby 2.4, these are a syntax error. I don't see an easy way of representing such strings. Right now the parser actually crashses (in all versions) so I'd say it's an improvement.
Compatible with Ruby up to 3.3. But compatibility with Ruby 3.4 is not yet available.
* * YARD docs for Parser::CurrentRuby * Document the transtion for users seeking Ruby 3.4 support * Allow IDE tools like Solargraph to understand the invocation and results from Parser::Current.parse() to provide auto-completion and type checking * * Add type info for Parser::Base#version
Ruby 3.3.8 has been released: https://www.ruby-lang.org/en/news/2025/04/09/ruby-3-3-8-released/ Bump 3.3 branch from 3.3.7 to 3.3.8 ruby/ruby@v3_3_7...v3_3_8 There seems to be no change to syntax.
The compatible version for Ruby 3.3.8 is Parser 3.3.8.x. Parser 3.3.7.5 was mistakenly relea 83B6 sed and has been yanked, then re-released as 3.3.8.0.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )