[ruby-core:108838] [Ruby master Feature#18159] Integrate functionality of dead_end gem into Ruby

Issue #18159 has been updated by schneems (Richard Schneeman).


Thanks you for the patch. I am not the best to review the C code but I have looked at it. Notably the test seems to indicate that my prior problems of "cannot monkeypatch" have been addressed:

```
      e = assert_raise(SyntaxError) do
        eval("def", nil, "test_syntax_error.rb")
      end
      assert_equal("test_syntax_error.rb", e.path)
```

If that's the case my updated requirements (with your patch) would be:


- Does not work with streaming code from STDIN (i.e. `echo 'def bad' | ruby` )
  - Possible memory bloat with enabling SCRIPT_LINES__ by default to obtain streaming contents.
- Does not work when executing a file directly (i.e. `ruby bad.rb`)
  - Cannot get source code (Possibly addressed by the addition of `SyntaxError#path`
- Does not work with eval
  - Cannot get source code
- Does not work with ruby -e command.
  - Cannot get source code


One idea: In addition to the `SyntaxError#path`, is it possible to also attach the source code the parser was just looking at maybe an API like `SyntaxError#source_contents`? That would address accessing code with all scenarios above. Alternatively, if we can get contents via `SCRIPT_LINES__` maybe some other interface could be introduced to store the contents of any script with the file name `-` that is loaded. It would increase memory, but not nearly as much as keeping ALL loaded files. I think it would be acceptable. Maybe use a similar interface. Maybe something like: `LAST_ANON_SCRIPT__`. Again I have little insight into what's easy or possible in terms of changes.

It's maybe worth asking as well, how confident is Ruby core that this is a feature they want? Basically: I am worried that if I ask you for too many changes or new interfaces and then it is decided that the feature is not desired then it will be wasting your time. Do you know if many have played around with adding the Gemfile to their applications? I am very happy to adapt `dead_end` to use new interfaces and I am very appreciative of your work here.

On my end, I'll need to fashion a way to pull in Ruby HEAD once your changes are merged on CI as my current tests rely on using the released preview version. Other than that I don't have any tasks on my plate for this Ruby 3.2 integration. Tests are failing currently on my branch, but I believe it's not due to my code https://github.com/ruby/ruby/pull/5859#issuecomment-1148895865. I'm occasionally working on an updated re-write of the algorithm as well in a PR, but it is experimental and is not a blocker.

----------------------------------------
Feature #18159: Integrate functionality of dead_end gem into Ruby
https://bugs.ruby-lang.org/issues/18159#change-97916

* Author: duerst (Martin D端rst)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.1
----------------------------------------
Missing 'end' errors are difficult to fix. We should integrate the functionality of the dead_end gem (https://github.com/zombocom/dead_end) into Ruby similar to how we integrated did_you_mean. It would greatly help programming Ruby, in particular for beginners.

See also Ruby Kaigi Takeout 2021 talk by Richard Schneeman https://rubykaigi.org/2021-takeout/presentations/schneems.html.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>