`defined?(@ivar)` on the non main Ractor has two issues:
1. raising an exception
```ruby
class C
@iv1 = []
def self.defined_iv1 = defined?(@iv1)
end
Ractor.new{
p C.defined_iv1
#=> can not get unshareable values from instance variables of classes/modules from non-main Ractors (Ractor::IsolationError)
}.take
```
-> Do not raise an exception but return `"instance-variable"` because
it is defined.
2. returning `"instance-variable"` if there is not defined.
```
class C
# @iv2 is not defined
def self.defined_iv2 = defined?(@iv2)
end
Ractor.new{
p C.defined_iv2 #=> "instance-variable"
}.take
```
-> returns `nil`
This confused me for a few minutes -- the testcase for
https://bugs.ruby-lang.org/issues/14834 was mistyped in the file name,
as well as once in the source.
E.g. in some cases it was
`one-four-three-eight-four` instead of
`one-four-eight-three-four`.
* YJIT: increase context cache size to 1024 redux
* Move context hashing code outside of unsafe block
* Avoid allocating large table on the stack, which would cause a stack overflow
Co-authored by Alan Wu @XrXr
This commit prevents the following unary operators from being accepted
as the value prefix of a block's optional parameter:
- `+`
- `-`
- `~`
- `!`
For example, `f { |a = +b| }` will now raise a syntax error.
https://github.com/ruby/prism/commit/3024bee60c
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
This allows the user to specify exception classes to treat as regular
exceptions instead of being swallowed. Among other things, it is
useful for having Logger work with Timeout.
Fixes Ruby Bug 9115.
https://github.com/ruby/logger/commit/436a7d680f
This commit creates a new directory `gc` to put different GC
implementations and moves the default GC from gc_impl.c to gc/gc_impl.c.
The default GC can be easily switched using the `BUILTIN_GC` variable
in Makefile.in.
[Bug #20593]
It's fairly common to use `format` to interpolate a number of values
into a user provided strings.
The arguments not matching are a problem when they are positional,
but when they are named, it's absolutely fine and we shouldn't
emit a warning.
Treat this similar to keyword splatting nil, using goto ignore.
However, keep previous behavior if the method accepts a keyword
splat, to avoid double hash allocation.
This also can avoid an array allocation when calling a method
that doesn't have any splat parameters but supports literal
keyword parameters, because ignore_keyword_hash_p was not
ignoring the keyword hash in that case.
This change doesn't remove the empty ruby2_keywords hash from
the array, which caused an assertion failure if the method
being called accepted keywords in some cases. Modify the
assertion to handle this case. An alternative approach would
add a flag to the args struct so the args_argc calculation could
handle this case and report the correct argc, but such an approach
would likely be slower.
