-
Notifications
You must be signed in to change notification settings - Fork 173
Add Ripper :on_sp events for Prism.lex_compat and Prism::Translation::Ripper #3859
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
Conversation
|
Failures that were added to excludes: |
|
And more complex cases like Would there be any way to get the correct state with Prism? |
|
I would not bother with comparing state for this. I'm not particularly motivated to understand what is happening in detail here. I doubt anyone is relying on this information being correct. |
|
Yeah it's what I'm doing in test/prism/ruby/ripper_test.rb, I'm ignoring the state of Slightly related, is |
Just putting in the state from the previous token seems fine. When it lines up, great. If not, oh well. Doesn't really matter in what way it's wrong.
I believe that is what ripper itself does. I haven't benchmarked this in detail yet but there are definitly some hotspots. Much time is spend sorting tokens by location for example. If changing this makes a noticable difference, I wouldn't be opposed to it. Here's what I use to quickly check: require "ripper"
require "prism"
require "benchmark/ips"
codes = Dir["**/*.rb"].map { File.read(it) }
Benchmark.ips do |x|
x.report("prism") { codes.each { Prism::Translation::Ripper.lex(it) } }
x.report("ripper") { codes.each { Ripper.lex(it) } }
x.compare!
endI was also a bit concerned about the performance of this implementation but it is not so bad. Compared to ripper it goes from 2.3x times slower to 2.6x times slower which seems fine. |
Earlopain
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still a draft but this is basically good to me.
e214296 to
68a45bc
Compare
|
f9acebf to
b7336e8
Compare
|
Taking notes, next failure is # top-100-gems/graphql-2.0.21/lib/generators/graphql/install/mutation_root_generator.rb
end
end #<trailing space here- [[34, 0], :on_kw, "end", END],
- [[34, 3], :on_sp, " ", END]]
+ [[34, 0], :on_kw, "end", END]]UPDATE: fixed now |
2541426 to
c29d8a9
Compare
|
The BOM (byte order mark) edge cases are madness but I think I got them correct now 😅 |
09be2ee to
3062051
Compare
Earlopain
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm somewhat surprised that this seems to handle all the cases. Nice work.
rbi/prism/parse_result.rbi
Outdated
|
|
||
| sig { params(byte_offset: Integer, length: Integer).returns(String) } | ||
| def slice(byte_offset, length); end | ||
| def slice(...); end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't know if this is ok. It typechecks but that's about it about my knowledge. I hate fighting with these tools. I'm just going to revert this and update the two places that pass a range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read some Sorbet docs and asked ChatGPT and basically Sorbet seems to not really support ....
I tried just leaving sig { returns(String) } but it was not happy about it.
Maybe overloads like this would work:
sig { overload.params(a: Integer, b: Integer).void }
sig { overload.params(r: T::Range[Integer]).void }
def slice(*args); endBut it feels complicated and duplicating the type of byteslice, hence just def slice(...); end felt simpler.
It'd be nice if we could say "this has the exact same type as String#byteslice".
| @@ -0,0 +1 @@ | |||
| p (42) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commited the two snapshots as well. Basically they get created when when running bundle exec rake
| --ignore=rakelib/ | ||
| --ignore=Rakefile | ||
| --ignore=top-100-gems/ | ||
| #{Dir.glob("*.rb").map { |f| "--ignore=/#{f}" }.join("\n")} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice, thanks
…:Ripper * Handle line continuations. * Handle space at the end of file in LexCompat. Co-authored-by: Earlopain <14981592+Earlopain@users.noreply.github.com>
3062051 to
32bd13e
Compare
|
This causes test failures in |
It used to not emit this token type, but now it does. So when a newer version of prism is present, we can fall back to the same code that ripper uses. Ref: * ruby/ruby#15914 * ruby/prism#3859
It used to not emit this token type, but now it does. So when a newer version of prism is present, we can fall back to the same code that ripper uses. Ref: * ruby/ruby#15914 * ruby/prism#3859
It used to not emit this token type, but now it does. So when a newer version of prism is present, we can fall back to the same code that ripper uses. Ref: * ruby/ruby#15914 * ruby/prism#3859
|
@Earlopain Oh, sorry about that, I didn't expect that would break. |
It used to not emit this token type, but now it does. So when a newer version of prism is present, we can fall back to the same code that ripper uses. Ref: * ruby/ruby#15914 * ruby/prism#3859
It used to not emit this token type, but now it does. So when a newer version of prism is present, we can fall back to the same code that ripper uses. Ref: * ruby/ruby#15914 * ruby/prism#3859
Ref: #3838
On top of #3858 should be merged first.