This caused an issue when `defined?` was in the `if` condition. Its
instructions weren't appended to the instruction sequence even though it was compiled
if a compile-time known logical short-circuit happened before the `defined?`. The catch table
entry (`defined?` compilation produces a catch table entry) was still on the iseq even though the
instructions weren't there. This caused faulty exception handling in the method.
The solution is to no add the catch table entry for `defined?` after a compile-time known logical
short circuit.
This shouldn't touch much code, it's only for cases like the following,
which can occur during debugging:
if false && defined?(Some::CONSTANT)
"more code..."
end
Fixes [Bug #20501]
This commit switches the default parser to Prism. There are a
couple of additional changes related to this that are a part of
this as well to make this happen.
* Switch the default parser in parse.h
* Remove the Prism-specific workflow and add a parse.y-specific
workflow to CI so that it continues to be tested
* Update a few test exclusions since Prism has the correct
behavior but parse.y doesn't per
https://bugs.ruby-lang.org/issues/20504.
* Skips a couple of tests on RBS which are failing because they
are using RubyVM::AbstractSyntaxTree.of.
Fixes [Feature #20564]
Since universal-parser and prism support, prelude code used functions
inaccessible from outside libruby shared library.
```
linking goruby
/usr/bin/ld: goruby.o: in function `prelude_eval':
/home/runner/work/ruby/ruby/build/golf_prelude.c:221: undefined reference to `rb_ruby_prism_ptr'
/usr/bin/ld: goruby.o: in function `pm_prelude_load':
/home/runner/work/ruby/ruby/build/golf_prelude.c:192: undefined reference to `pm_options_line_set'
/usr/bin/ld: /home/runner/work/ruby/ruby/build/golf_prelude.c:193: undefined reference to `pm_parse_string'
/usr/bin/ld: goruby.o: in function `prelude_eval':
/home/runner/work/ruby/ruby/build/golf_prelude.c:224: undefined reference to `pm_iseq_new_with_opt'
/usr/bin/ld: /home/runner/work/ruby/ruby/build/golf_prelude.c:226: undefined reference to `pm_parse_result_free'
/usr/bin/ld: goruby.o: in function `prelude_ast_value':
/home/runner/work/ruby/ruby/build/golf_prelude.c:181: undefined reference to `rb_ruby_ast_data_get'
/usr/bin/ld: goruby.o: in function `prelude_eval':
/home/runner/work/ruby/ruby/build/golf_prelude.c:231: undefined reference to `rb_ruby_ast_data_get'
/usr/bin/ld: goruby.o: in function `pm_prelude_load':
/home/runner/work/ruby/ruby/build/golf_prelude.c:196: undefined reference to `pm_parse_result_free'
collect2: error: ld returned 1 exit status
```
Although `pend` in test-unit gem expects the block does not pass if it
is given, our `pend` should ignore the block silently as same as it
just skips the test with no message by default. Add an unused
parameter, to suppress the warning for the block to be ignored.
The default version of securerandom (0.2.2) gets activated by RubyGems,
but does not match Rails requirements (>= 0.3), leading to an error like
this:
```
$ gem exec rails new repro
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:2246:in `raise_if_conflicts': Unable to activate activesupport-7.2.1, because securerandom-0.2.2 conflicts with securerandom (>= 0.3) (Gem::ConflictError)
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1383:in `activate'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1421:in `block in activate_dependencies'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `each'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `activate_dependencies'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1385:in `activate'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `block in gem'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `synchronize'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `gem'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:193:in `activate!'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:73:in `execute'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:326:in `invoke_with_build_args'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:255:in `invoke_command'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:194:in `process_args'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:152:in `run'
from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:56:in `run'
from /Users/deivid/code/rubygems/rubygems/exe/gem:12:in `<main>'
```
Vendoring our own securerandom fixes the issue since that way we avoid
activating the gem internally.
The `rev && has_commit(rev, "ruby_#{TARGET_VERSION.tr('.','_')}")`
case seems to be used if and only if it's manually specified in the
argument to the done command. It was hard to notice it with the previous
code.
Make Range#step to consistently use + for iteration [Feature #18368]
Previously, non-numerics expected step to be integer,
and iterated with begin#succ, skipping over step value
steps. Since this commit, numeric and non-numeric iteration
behaves the same way, by using + operator.
Peter Zhu
Samuel Giddins
Nobuyoshi Nakada
Hiroshi SHIBATA
Kazuhiro NISHIYAMA
Soutaro Matsumoto
Luke Gruber
David Rodríguez
Kevin Newton
Yusuke Endoh
ydah
Takashi Kokubun
git
Victor Shepelev
tomoya ishida