| Age | Commit message (Collapse) | Author |
|
|
|
|
|
https://github.com/ruby/prism/commit/21c499d6e4
|
|
https://github.com/ruby/prism/commit/138db9ccc4
|
|
It's https://rubygems.org/gems/sexp_processor, not https://rubygems.org/gems/sexp
https://github.com/ruby/prism/commit/b8a00a5f15
|
|
ruby_parser.
Had to add a require of sexp since that came in indirectly via ruby_parser.
https://github.com/ruby/prism/commit/df677c324f
|
|
Tests were failing in Flay under Prism.
https://github.com/ruby/prism/commit/af9b3640a8
|
|
Otherwise, it uses the latest prism version
https://github.com/ruby/prism/commit/86406f63aa
|
|
This is more concise and ruby does a better job performance-wise.
This used to be `bsearch_index` already but https://github.com/ruby/prism/commit/6d8358c08395438d5924777c1fc3001a5ebf0aa3 changed it.
https://github.com/ruby/prism/pull/1733#discussion_r1373702087 said:
> Yeah the edge case was that the value matched an element exactly
But surely there would be a test to show this behaviour?
Gets called as part of pretty-printing nodes.
Further reduces the time for `SnapshotsTest` by ~16% for me.
https://github.com/ruby/prism/commit/f448e2b995
|
|
While the latter creates an intermediate array of all method names
including all ancestors, the former just traverse the inheritance
chain and can stop if found once.
https://github.com/ruby/prism/commit/6da384dd0e
|
|
See https://github.com/ruby/ruby/commit/6d81969b475262aba251e99b518181bdf7c5a523
It leaves the old variant around. RuboCop for examples accesses `Prism::Translation::Parser35`
to test against ruby-head. For now I left these simply as an alias
https://github.com/ruby/prism/commit/d0a823f045
|
|
|
|
In the case of attribute writes, there are use cases where you want
to know the location of the = sign. (Internally we actually need
this for translation to the writequark AST.)
https://github.com/ruby/prism/commit/bfc798a7ec
|
|
https://github.com/ruby/prism/commit/b72fcc6183
|
|
The docs currently say to use `Prism.parse(foo, version: RUBY_VERSION)` for this.
By specifying "current" instead, we can have prism raise a more specifc error.
Note: Does not use `ruby_version` from `ruby/version.h` because writing a test for that is not really possible.
`RUBY_VERSION` is nicely stubbable for both the c-ext and FFI backend.
https://github.com/ruby/prism/commit/9c5cd205cf
|
|
https://github.com/ruby/prism/commit/7574837b7b
|
|
Symbol#name is only a thing since Ruby 3.0
https://github.com/ruby/prism/commit/2de82b15fc
|
|
An unspecified uplevel is not the same as an uplevel of 1:
```
$ irb
irb(main):001> warn("foo")
foo
=> nil
irb(main):002> warn("foo", uplevel: 1)
/home/user/.rbenv/versions/2.7.8/lib/ruby/gems/2.7.0/gems/irb-1.14.0/lib/irb/workspace.rb:121: warning: foo
=> nil
```
https://github.com/ruby/prism/commit/dcedd14357
|
|
Make it clear that it parses with the most recent version of Ruby
syntax.
https://github.com/ruby/prism/commit/7285d1fbab
|
|
https://github.com/ruby/prism/commit/cac5118884
|
|
https://github.com/ruby/prism/commit/194edab827
|
|
The same also applies to `break`/`next`.
https://bugs.ruby-lang.org/issues/21540
https://github.com/ruby/prism/commit/3a38b192e3
|
|
Generally I have been good about safely accessing the tokens but failed
to properly guard against no tokens in places
where it could theoretically happen through invalid syntax.
I added a test case for one occurance, other changes are theoretical only.
https://github.com/ruby/prism/commit/4a3866af19
|
|
The purpose of this commit is to fix Bug #21188. We need to detect when
stdin has run in to an EOF case. Unfortunately we can't _call_ the eof
function on IO because it will block.
Here is a short script to demonstrate the issue:
```ruby
x = STDIN.gets
puts x
puts x.eof?
```
If you run the script, then type some characters (but _NOT_ a newline),
then hit Ctrl-D twice, it will print the input string. Unfortunately,
calling `eof?` will try to read from STDIN again causing us to need a
3rd Ctrl-D to exit the program.
Before introducing the EOF callback to Prism, the input loop looked
kind of like this:
```ruby
loop do
str = STDIN.gets
process(str)
if str.nil?
p :DONE
end
end
```
Which required 3 Ctrl-D to exit. If we naively changed it to something
like this:
```ruby
loop do
str = STDIN.gets
process(str)
if STDIN.eof?
p :DONE
end
end
```
It would still require 3 Ctrl-D because `eof?` would block. In this
patch, we're wrapping the IO object, checking the buffer for a newline
and length, and then using that to simulate a non-blocking eof? method.
This commit wraps STDIN and emulates a non-blocking `eof` function.
[Bug #21188]
|
|
https://github.com/ruby/prism/commit/9f55551b09
|
|
https://github.com/ruby/prism/commit/c2e372a8d8
|
|
This makes it hard to do version checks against this value. The current version checks work because there are so few possible values at the moment.
As an example, PR 3337 introduces new syntax for ruby 3.5 and uses `PM_OPTIONS_VERSION_LATEST` as its version guard. Because what is considered the latest changes every year, it must later be changed to `parser->version == parser->version == PM_OPTIONS_VERSION_CRUBY_3_5 || parser->version == PM_OPTIONS_VERSION_LATEST`, with one extra version each year.
With this change, the PR can instead write `parser->version >= PM_OPTIONS_VERSION_CRUBY_3_5` which is self-explanatory
and works for future versions.
https://github.com/ruby/prism/commit/8318a113ca
|
|
https://docs.ruby-lang.org/en/master/syntax/literals_rdoc.html#label-25w+and+-25W-3A+String-Array+Literals
> %W allow escape sequences described in Escape Sequences. However the continuation line <newline> is not usable because it is interpreted as the escaped newline described above.
https://github.com/ruby/prism/commit/f5c7460ad5
|
|
Instead, prefer `scan_byte` over `get_byte` since that already returns the byte as an integer, sidestepping conversion issues.
Fixes https://github.com/ruby/prism/issues/3582
https://github.com/ruby/prism/commit/7f3008b2b5
|
|
https://github.com/ruby/prism/commit/571ba378f5
|
|
https://github.com/ruby/prism/commit/de1faa1680
|
|
https://github.com/ruby/prism/commit/641775e5fe
|
|
https://github.com/ruby/prism/commit/12af4e144e
|
|
Given this code
```ruby
begin
raise '42'
rescue => A[]
end
```
Prism fails with this backtrace
```
Error: test_unparser/corpus/literal/rescue.txt(Prism::ParserTest): NoMethodError: undefined method `arguments' for nil
prism/lib/prism/translation/parser/compiler.rb:1055:in `visit_index_target_node'
prism/lib/prism/node.rb:9636:in `accept'
prism/lib/prism/compiler.rb:30:in `visit'
prism/lib/prism/translation/parser/compiler.rb:218:in `visit_begin_node'
```
Seems like
```diff
- visit_all(node.arguments.arguments),
+ visit_all(node.arguments&.arguments || []),
```
fixes the problem.
https://github.com/ruby/prism/commit/76d01aeb6c
|
|
Because it ends up treating it as a local variable, and `a.x`
is not a valid local variable name.
I'm not big on pattern matching, but conceptually it makes sense to me
to treat anything inside ^() to not be
pattern matching syntax?
https://github.com/ruby/prism/commit/80dbd85c45
|
|
`StringNode` and `SymbolNode` don't have the same shape
(`content` vs `value`) and that wasn't handled.
I believe the logic for the common case can be reused.
I simply left the special handling for implicit nodes in pattern matching
and fall through otherwise.
NOTE: patterns.txt is not actually tested at the moment,
because it contains syntax that `parser` mistakenly rejects.
But I checked manually that this doesn't introduce other failures.
https://github.com/whitequark/parser/pull/1060
https://github.com/ruby/prism/commit/55adfaa895
|
|
[Bug #21197]
https://github.com/ruby/prism/commit/22be955ce9
Notes:
Merged: https://github.com/ruby/ruby/pull/12999
|
|
https://github.com/ruby/prism/commit/594e2a69ed
|
|
There hasn't been much that would actually affect parsers usage of it.
But, when adding new node types, these usually appear in the `Parser::Meta::NODE_TYPES`.
`itblock` was added, gets emitted by prism, and then `rubocop-ast` blindly delegates to `on_itblock`.
These methods are dynamically created through `NODE_TYPES`, which means that it will error if it
doesn't contain `itblock`.
This is unfortunate because in `rubocop-ast` these methods are eagerly defined but
the prism translator is lazily loaded on demand.
The simplest solution is to add them on the `parser` side (even if they are not emitted directly), and require that a version that contains those be used.
In summary when adding a new node type:
* Add it to `Parser::Meta::PRISM_TRANSLATION_PARSER_NODE_TYPES` (gets included in `NODE_TYPES`)
* Bump the minimum `parser` version used by `prism` to a version that contains the above change
* Actually emit that node type in `prism`
https://github.com/ruby/prism/commit/d73783d065
|
|
There will be a bunch of other problems should 3.10 ever exists, but I guess why not fix this one now.
https://github.com/ruby/prism/commit/b385f47f8b
|
|
It's not my favorite api but for users that currently use the same thing
from `parser`, moving over is more difficult
than it needs to be.
If you plan to support both old and new ruby versions, you definitly need to
branch somewhere on the ruby version
to either choose prism or parser.
But with prism you then need to enumerate all the versions again and choose the correct one.
Also, don't recommend to use `Prism::Translation::Parser` in docs. It's version-less
but actually always just uses Ruby 3.4 which is probably
not what the user intended.
Note: parser also warns when the patch version doesn't match what it expects. But I don't think prism has such a concept,
and anyways it would require releases anytime ruby releases, which I don't think is very desirable
https://github.com/ruby/prism/commit/77177f9e92
|
|
https://github.com/ruby/prism/commit/c02429765b
|
|
https://github.com/ruby/prism/commit/d85c72a1b9
|
|
`category` is only supported from Ruby 3.0 onwards and prism can still run with Ruyb 2.7
https://github.com/ruby/prism/commit/335a193851
|
|
builder class
In https://github.com/ruby/prism/pull/3494 I added a bit of code
so that using the new builder doesn't break stuff.
This code can be dropped when it is enforced that builder
is _always_ the correct subclass (and makes future issues like that unlikely).
https://github.com/ruby/prism/commit/193d4b806d
|
|
https://github.com/ruby/prism/commit/71d31db496
|
|
|
|
Caused by https://github.com/ruby/prism/pull/3478 and https://github.com/ruby/prism/pull/3443
I also made the builder reference more explicit to clearly distinquish
between `::Parser` and `Prism::Translation::Parser`
https://github.com/ruby/prism/commit/d52aaa75b6
|
|
```
(a,), = []
PARSER====================
s(:masgn,
s(:mlhs,
s(:mlhs,
s(:lvasgn, :a))),
s(:array))
PRISM====================
s(:masgn,
s(:mlhs,
s(:lvasgn, :a)),
s(:array))
```
https://github.com/ruby/prism/commit/8aa1f4690e
|
|
In https://github.com/ruby/prism/commit/26370079291a420c6b2b7be5cdbd5c609da62f21 I added tests but didn't modify them correctly
https://github.com/ruby/prism/commit/de021e74de
|