From: "Eregon (Benoit Daloze) via ruby-core" Date: 2026-10-07T22:43:22+00:00 Subject: [ruby-core:126998] [Ruby Feature#22379] Remove prism mismatch warning from `#syntax_tree` Issue #22379 has been updated by Eregon (Benoit Daloze). Overall I think this is a great solution for making `#syntax_tree` reliable. I asked Claude to think about the consequences of introducing `Ruby::Prism`: --- It recreates the `ripper` / `parser` gem split. Code that parses the running program (`error_highlight`, `syntax_suggest`, `irb`, debuggers, coverage tools) would move to `Ruby::Prism` and be better off: no dependency, no `Gemfile` conflict, tree always matching the interpreter. Cross-version tooling (RuboCop, Ruby LSP, Sorbet, Herb) cannot move: a `Ruby::Prism` frozen at the 4.1 snapshot cannot parse 4.2 syntax, and these tools also support older Rubies and `--parser=parse.y`, where `Ruby::Prism` does not exist. The two copies are the permanent end state, not a transitional cost. Given that: 1. `Ruby::Prism` becomes a public API frozen per Ruby minor version, with parser fixes only arriving through Ruby patch releases. Prism changes node shapes far more often than ripper did, so this should be documented as the intended contract. 2. Trimming the API to nodes and core functions does not work: the runtime tools are exactly the users of `Visitor`, `Pattern`, `Dispatcher` and `Relocation`. Only `Prism::Translation` clearly does not belong. 3. Upstream prism has to stay compatible with the textual namespace rewrite in `tool/sync_default_gems.rb` (no `Prism` constant in strings, `const_get`, error messages) for as long as this exists. 4. Alternative implementations need to ship `Ruby::Prism` too, locked to their own parser version. For TruffleRuby this is mostly importing `lib/ruby/prism` and pointing the FFI backend at the libprism it already ships. None of this is a blocker, but I think the proposal should be framed as a stable built-in parser API for introspecting the running program, next to the prism gem for cross-version tooling, with the compatibility expectations that implies. --- Additionally I worry that gems which want to use `Ruby::Prism` may have trouble with multiple versions of `Ruby::Prism` (from different releases) and when mixing both APIs (which they need until they drop Ruby 4.0 support), as the API may change in incompatible ways between versions (e.g. [breaking changes](https://github.com/ruby/prism/blob/main/CHANGELOG.md) between Prism 1.x and 2.x). Ruby will also end up picking the latest Prism at the time of the Ruby X.Y.0 release and those might not correspond in terms of major changes (e.g. Ruby 4.1 with Prism 2.0 having some incompatibilities with Prism 1.x). I think care in Prism to avoid breaking changes can go a long way to address this, and it seems mostly the case already. IOW, what users of `Ruby::Prism` lose is the ability to specify the Prism version and so to not have to deal with multiple Prism versions. They also cannot get a fix as fast by updating the gem, by with frequent CRuby releases this matters less. ---------------------------------------- Feature #22379: Remove prism mismatch warning from `#syntax_tree` https://bugs.ruby-lang.org/issues/22379#change-119391 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- #21795 added `#syntax_tree` for a few objects. Currently it is implemented in a way that uses the prism gem, using node_id. Because it is theoretically possible that node_ids from the internal cruby version of prism don't match with the node_ids from the installed prism gem, a warning is emitted when the two versions don't match: ```rb def x = nil pp method(:x).syntax_tree # => syntax_tree: a prism gem other than the default gem is loaded; the result may not correspond exactly to the compiled code # => @ DefNode (location: (1,0)-(1,11)) # ... ``` That this version-mismatch happens is basically a given. As soon as the user has prism in their lockfile for any reason it will be triggered. When I encounter a warning I assume that I have to make some change in the code to avoid it but there is nothing realistic for me to do, except to stop using the method alltogether. The warning is verbose-only. However it's good practise to run test suites with warnings enabled to keep up on deprecations, so even there it does not fit. I would like this warning to become documentation only for the above reasons. @eregon also suggested to only warn when we can prove that the node_id doesn't match. That should be possible as well, since we have the code location from the iseq and can check if the node we found via prism lines up. However, that doesn't guarantee that the contents of the node are also the same. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/