| Age | Commit message (Collapse) | Author |
|---|
|
builds
Previously, RBIMPL_ASSERT_TYPE() used Check_Type() only in RUBY_DEBUG
builds. It raised TypeError, but only in debug builds. For people testing
type mismatch using debug builds looking for a Ruby exception, this can
be misleading -- the code could be missing a type check in non-debug builds
if it is relying on for example RSTRING_LEN() to raise.
Also, Check_Type() can obscure the true cause of error in debug mode.
When type check fails because the object is corrupt, instead of crashing
with a clear type assertion message, it can crash while trying to
construct an exception object to raise. You can see this for example in
<https://github.com/ruby/ruby/actions/runs/9489999591/job/26152506434?pr=10985>,
where RB_ENCODING_GET() is used on a corrupt object, but the crash
happens later and says "Assertion Failed:
../src/vm_method.c:1477:callable_method_entry_or_negative".
RBIMPL_ASSERT_TYPE() should assert right away.
RBIMPL_ASSERT_OR_ASSUME() asserts when RUBY_DEBUG and assumes in release
builds, as desired.
This should help investigate flaky CI failures that show up as TypeError
from `Kernel#require`, e.g.
"'Kernel#require': wrong argument type false (expected String) (TypeError)".
Same CI failure examples:
- https://github.com/ruby/ruby/actions/runs/9034787861/job/24828147431
- https://github.com/ruby/ruby/actions/runs/9418303667/job/25945492440
- https://github.com/ruby/ruby/actions/runs/9505650952/job/26201031314
The failure occurs with and without use of YJIT.
|
|
[Feature #19998]
|
|
[Feature #20205]
Now that chilled strings no longer appear as frozen, there is no
need to offer an API to check for chilled strings.
We however need to change `rb_check_frozen_internal` to no
longer be a macro, as it needs to check for chilled strings.
|
|
[Feature #20507]
This was missed from the initial commit.
```
../../.././include/ruby/internal/value_type.h:446:27: error: implicit conversion changes signedness: 'enum ruby_value_type' to 'int' [-Werror,-Wsign-conversion]
rb_unexpected_type(v, t);
~~~~~~~~~~~~~~~~~~ ^
```
|
|
C extension maintainers can now compile with this warning option and
the Ruby header files will generate no warnings.
[Feature #20507]
|
|
They were initially made frozen to avoid false positives for cases such
as:
str = str.dup if str.frozen?
But this may cause bugs and is generally confusing for users.
[Feature #20205]
Co-authored-by: Jean Boussier <[email protected]>
|
|
|
|
We observe compiler error on FreeBSD. Their stdckdint.h does not
understand C++. This shall be addressed on their side. Unti then we
resport to our own version.
https://rubyci.s3.amazonaws.com/freebsd14/ruby-master/log/20240427T143002Z.log.html.gz
|
|
C23 is going to have this header. The industry is already moving
towards accepting it; OSes and compilers started to implement theirs.
Why not detect its presence and if any, prefer over other ways.
See also:
- https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2683.pdf
- https://reviews.freebsd.org/D41734
- https://reviews.llvm.org/D157331
- https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8441841a1b985d68245954af1ff023db121b0635
|
|
ruby_coderange_type is defined in ruby/internal/encoding/coderange.h so
we need to include it.
|
|
|
|
and declare it will be removed soon.
ddtrace is still referes the API and build was failed.
See https://github.com/DataDog/dd-trace-rb/pull/3578
Maybe threre are only few users of this C-API now so we can remove
it soon.
|
|
This function has been deprecated since Ruby 3.1, so we should remove it
for Ruby 3.4.
|
|
Signed-off-by: crazeteam <[email protected]>
|
|
Some extensions (like stringio) may need to differentiate between
chilled strings and frozen strings.
They can now use rb_str_chilled_p but must check for its presence since
the function will be removed when chilled strings are removed.
[Bug #20389]
[Feature #20205]
Co-authored-by: Jean Boussier <[email protected]>
|
|
|
|
[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 <[email protected]>
|
|
|
|
|
|
This frees FL_USER0 on both T_MODULE and T_CLASS.
Note: prior to this, FL_SINGLETON was never set on T_MODULE,
so checking for `FL_SINGLETON` without first checking that
`FL_TYPE` was `T_CLASS` was valid. That's no longer the case.
|
|
Signed-off-by: cui fliter <[email protected]>
|
|
They are not only pinned, but also immortal. Even if the
constant referencing them is removed, they will remain alive.
It's a precision worth noting.
|
|
Use `_WIN64` for word-size, `_M_AMD64` for CPU-specific feature.
|
|
It is for dynamically loading, useless for statically linked objects.
|
|
|
|
This commit changes how stack extents are calculated for both the main
thread and other threads. Ruby uses the address of a local variable as
part of the calculation for machine stack extents:
* pthreads uses it as a lower-bound on the start of the stack, because
glibc (and maybe other libcs) can store its own data on the stack
before calling into user code on thread creation.
* win32 uses it as an argument to VirtualQuery, which gets the extent of
the memory mapping which contains the variable
However, the local being used for this is actually too low (too close to
the leaf function call) in both the main thread case and the new thread
case.
In the main thread case, we have the `INIT_STACK` macro, which is used
for pthreads to set the `native_main_thread->stack_start` value. This
value is correctly captured at the very top level of the program (in
main.c). However, this is _not_ what's used to set the execution context
machine stack (`th->ec->machine_stack.stack_start`); that gets set as
part of a call to `ruby_thread_init_stack` in `Init_BareVM`, using the
address of a local variable allocated _inside_ `Init_BareVM`. This is
too low; we need to use a local allocated closer to the top of the
program.
In the new thread case, the lolcal is allocated inside
`native_thread_init_stack`, which is, again, too low.
In both cases, this means that we might have VALUEs lying outside the
bounds of `th->ec->machine.stack_{start,end}`, which won't be marked
correctly by the GC machinery.
To fix this,
* In the main thread case: We already have `INIT_STACK` at the right
level, so just pass that local var to `ruby_thread_init_stack`.
* In the new thread case: Allocate the local one level above the call to
`native_thread_init_stack` in `call_thread_start_func2`.
[Bug #20001]
fix
|
|
This reverts commit 4ba8f0dc993953d3ddda6328e3ef17a2fc2cbde5.
|
|
The implementation of `native_thread_init_stack` for the various
threading models can use the address of a local variable as part of the
calculation of the machine stack extents:
* pthreads uses it as a lower-bound on the start of the stack, because
glibc (and maybe other libcs) can store its own data on the stack
before calling into user code on thread creation.
* win32 uses it as an argument to VirtualQuery, which gets the extent of
the memory mapping which contains the variable
However, the local being used for this is actually allocated _inside_
the `native_thread_init_stack` frame; that means the caller might
allocate a VALUE on the stack that actually lies outside the bounds
stored in machine.stack_{start,end}.
A local variable from one level above the topmost frame that stores
VALUEs on the stack must be drilled down into the call to
`native_thread_init_stack` to be used in the calculation. This probably
doesn't _really_ matter for the win32 case (they'll be in the same
memory mapping so VirtualQuery should return the same thing), but
definitely could matter for the pthreads case.
[Bug #20001]
|
|
|
|
#20005]
This is a C API for extensions to resolve and get function symbols of other extensions.
Extensions can check the expected symbol is correctly loaded and accessible, and
use it if it is available.
Otherwise, extensions can raise their own error to guide users to setup their
environments correctly and what's missing.
|
|
Instead of `RUBY_REFERENCES_START` and `RUBY_REFERENCES_END`, so that
auto-indent works well.
|
|
Also move `struct` so that `typedef`-ed names can be used.
|
|
|
|
Fixes:
```
/usr/local/ruby/include/ruby-3.3.0+0/ruby/internal/core/rtypeddata.h:467:33:
error: invalid conversion from ‘void*’ to ‘parser_t*’ [-fpermissive]
467 | (sval) = RTYPEDDATA_GET_DATA(result); \
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~
| |
| void*
```
|
|
This commit adds a new flag RUBY_TYPED_EMBEDDABLE that allows the data
of a TypedData object to be embedded after the object itself. This will
improve cache locality and allow us to save the 8 byte data pointer.
Co-Authored-By: Jean Boussier <[email protected]>
|
|
* rb_warn() does not warn if $VERBOSE is nil, the "always" is wrong.
* Talk about $VERBOSE and not -W since $VERBOSE can be changed at runtime.
|
|
|
|
|
|
Notes:
Merged-By: ioquatix <[email protected]>
|
|
cf: https://github.com/llvm/llvm-project/commit/874217f99b99ab3c9026dc3b7bd84cd2beebde6e
Notes:
Merged: https://github.com/ruby/ruby/pull/8274
|
|
Notes:
Merged-By: maximecb <[email protected]>
|
|
fix [Feature #19572]
Notes:
Merged: https://github.com/ruby/ruby/pull/8150
|
|
Since edf01d4e82d8e44ee30ec41fbcb7f802bc8b8c5d, fake string treats
NULL as an empty string.
|
|
|
|
|
|
RARRAY_CONST_PTR now does the same things as RARRAY_CONST_PTR_TRANSIENT.
Notes:
Merged: https://github.com/ruby/ruby/pull/8071
|
|
RARRAY_PTR_USE now does the same things as RARRAY_PTR_USE_TRANSIENT.
Notes:
Merged: https://github.com/ruby/ruby/pull/8071
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8071
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7942
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8066
|
