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

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


> ko1 (Koichi Sasada) and knu (Akinori MUSHA) were concerned about whether the heuristic algorithm was mature enough. If dead_end prints a misguided summary, it may rather confuse users.

I certainly understand and agree. If you (or anyone else) finds a strange case please let me know.

> The implementation uses timeout, five seconds by default. The heuristic algorithm may take so long time?

I added the timeout because if the algorithm has a bug that causes a slowdown or infinite loop, I still want the developer to know there is a syntax error without pretty output. In practice, it is speedy. The user should not notice any time between running their program and getting output. 

The only performance problem I've had since making the library was creating many combinations of a large array. I  fixed it in https://github.com/zombocom/dead_end/pull/35. On further review, I can be lazier with this combination generation which will help.

I do have a performance test just in case of regressions https://github.com/zombocom/dead_end/blob/5656caa3116f38b1d1b3ef139dc4c692d93d04b9/spec/perf/perf_spec.rb#L30.

I could likely reduce the timeout value to 1 second comfortably. It is already configurable via an environment variable for flexibility while debugging.

> The gem includes "exe/dead_end" command. Should it be shipped with the ruby tarball, too?

I added this to debug so someone can run the algorithm without having to execute any code or put `dead_end` in their Gemfile. I don't think it is necessary to ship the executable with Ruby.

> dead_end seems to extend NoMethodError to show a code snippet where the error occurs (if it is not running in production?). Does this conflict with error_highlight?

After seeing `highlight_error` (thank you for your work), I can remove this code from dead_end and encourage developers to add your gem instead.

> unfortunately it does not work because the current parser outputs an error message directly to tty, not via SyntaxError#message

I tried to hook into SyntaxError as my first attempt and learned that I could not patch it, but I didn't know why.

> Nobu (Nobuyoshi Nakada) is now trying to sort it out to allow the following API design. schneems (Richard Schneeman) What do you think?

I like this API. I wonder if there are other cases we want to support where the source is not on disk. The two cases I can think of are `eval` and streaming ruby code via STDIN:

```
$ echo "puts 1+1" | ruby
2
```

I think this feature is an enhancement that is not strictly necessary in all cases, but if I had the source contents instead of just the file path, then I think I'd be able to handle these additional edge cases.

> There are only three months until Ruby 3.1 release, so they suggested to try the integration towards Ruby 3.2.

Targeting 3.2 seems safer. I can begin making adjustments and preparations. Thank you for the opportunity 


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

* 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>