| Age | Commit message (Collapse) | Author |
|---|
|
For that particular spec, the empty lines' presence is not relevant.
So let's remove them to make the spec easier to maintain.
|
|
|
|
[Feature #18576]
Since outright renaming `ASCII-8BIT` is deemed to backward incompatible,
the next best thing would be to only change its `#inspect`, particularly
in exception messages.
|
|
* Improve consistency of `Fiber.current.raise`.
|
|
Accecpt the same arguments as `caller` and `caller_locations`.
|
|
|
|
|
|
|
|
[Feature #20205]
As a path toward enabling frozen string literals by default in the future,
this commit introduce "chilled strings". From a user perspective chilled
strings pretend to be frozen, but on the first attempt to mutate them,
they lose their frozen status and emit a warning rather than to raise a
`FrozenError`.
Implementation wise, `rb_compile_option_struct.frozen_string_literal` is
no longer a boolean but a tri-state of `enabled/disabled/unset`.
When code is compiled with frozen string literals neither explictly enabled
or disabled, string literals are compiled with a new `putchilledstring`
instruction. This instruction is identical to `putstring` except it marks
the String with the `STR_CHILLED (FL_USER3)` and `FL_FREEZE` flags.
Chilled strings have the `FL_FREEZE` flag as to minimize the need to check
for chilled strings across the codebase, and to improve compatibility with
C extensions.
Notes:
- `String#freeze`: clears the chilled flag.
- `String#-@`: acts as if the string was mutable.
- `String#+@`: acts as if the string was mutable.
- `String#clone`: copies the chilled flag.
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
|
|
|
|
[Feature #13557]
Setting the backtrace with an array of strings is lossy. The resulting
exception will return nil on `#backtrace_locations`.
By accepting an array of `Backtrace::Location` instance, we can rebuild
a `Backtrace` instance and have a fully functioning Exception.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
|
|
[Bug #20188]
Ref: https://github.com/fxn/zeitwerk/issues/281#issuecomment-1893228355
Previously, it would only return the real constant location once the
autoload was fully completed.
|
|
|
|
|
|
irb will load multiple rc files now. If developer have their rcfile on
home directory or etc, equal assertion will fail with custom prompt.
|
|
|
|
Fixes [Bug #5179]
|
|
|
|
|
|
library/bigdecimal
|
|
|
|
[Bug #20253]
All the way down to Ruby 1.9, `Proc`, `Method`, `UnboundMethod`
and `Binding` always had their own specific clone and dup routine.
This caused various discrepancies with how other objects behave
on `dup` and `clone. [Bug #20250], [Bug #20253].
This commit get rid of `CLONESETUP` and use the the same codepath
as all other types, so ensure consistency.
NB: It's still not accepting the `freeze` keyword argument on `clone`.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
|
|
|
|
|
|
is defined
|
|
spec/ruby/core/rational/coerce_spec.rb
|
|
spec/mspec/tool/wrap_with_guard.rb 'ruby_version_is ""..."3.4"' spec/ruby/core/integer/coerce_spec.rb
spec/mspec/tool/wrap_with_guard.rb 'ruby_version_is ""..."3.4"' spec/ruby/shared/rational/coerce.rb
spec/mspec/tool/wrap_with_guard.rb 'ruby_version_is ""..."3.4"' spec/ruby/library/bigmath/log_spec.rb
and example of at_spec.rb
|
|
|
|
|
|
|
|
|
|
|
|
Since Ruby 3.0, Ruby has passed a keyword splat as a regular
argument in the case of a call to a Ruby method where the
method does not accept keyword arguments, if the method
call does not contain an argument splat:
```ruby
def self.f(obj) obj end
def self.fs(*obj) obj[0] end
h = {a: 1}
f(**h).equal?(h) # Before: true; After: false
fs(**h).equal?(h) # Before: true; After: false
a = []
f(*a, **h).equal?(h) # Before and After: false
fs(*a, **h).equal?(h) # Before and After: false
```
The fact that the behavior differs when passing an empty
argument splat makes it obvious that something is not
working the way it is intended. Ruby 2 always copied
the keyword splat hash, and that is the expected behavior
in Ruby 3.
This bug is because of a missed check in setup_parameters_complex.
If the keyword splat passed is not mutable, then it points to
an existing object and not a new object, and therefore it must
be copied.
Now, there are 3 specs for the broken behavior of directly
using the keyword splatted hash. Fix two specs and add a
new version guard. Do not keep the specs for the broken
behavior for earlier Ruby versions, in case this fix is
backported. For the ruby2_keywords spec, just remove the
related line, since that line is unrelated to what the
spec is testing.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
|
|
|
|
|
|
Otherwise you can have work in some circumstance but not in others.
|
|
|
|
Enable the test commented out in ruby/ruby@d0f5dc9eac78ecade459.
Extracted from GH-7033, that is for initialization at start up time
and this test is unrelated to it.
|
|
This patch introduce M:N thread scheduler for Ractor system.
In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.
From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.
Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.
There are additional settings by environment variables:
`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).
`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).
This patch will be reverted soon if non-easy issues are found.
[Bug #19842]
|
|
Remove the bad example that can lead to misunderstanding as if this
precision is defined in Ruby.
|
|
|
|
Previously, Kernel#lambda returned a non-lambda proc when given a
non-literal block and issued a warning under the `:deprecated` category.
With this change, Kernel#lambda will always return a lambda proc, if it
returns without raising.
Due to interactions with block passing optimizations, we previously had
two separate code paths for detecting whether Kernel#lambda got a
literal block. This change allows us to remove one path, the hack done
with rb_control_frame_t::block_code introduced in 85a337f for supporting
situations where Kernel#lambda returned a non-lambda proc.
[Feature #19777]
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/8405
|
|
|
|
- String#start_with?
- String#delete_prefix
- String#delete_prefix!
Notes:
Merged: https://github.com/ruby/ruby/pull/8296
|
|
* Skip RBS test.
Notes:
Merged-By: ioquatix <samuel@codeotaku.com>
|
|
https://github.com/ruby/ruby/actions/runs/5956398507/job/16157091112
This has been extremely flaky on macOS GitHub Actions.
Benoit suggested to quarantine it if it's too problematic (it is) and
there's no reasonable fix in a short time (it already took too long).
So this commit follows the suggestion.
We should remove revert this once rb_cloexec_open() is fixed.
|
|
Deprecate Kernel#open and IO support for subprocess creation and
forking. This deprecates subprocess creation and forking in
- Kernel#open
- URI.open
- IO.binread
- IO.foreach
- IO.readlines
- IO.read
- IO.write
This behavior is slated to be removed in Ruby 4.0
[Feature #19630]
Notes:
Merged: https://github.com/ruby/ruby/pull/7915
|
|
|
|
|
