Has been deprecated since 684bdf6171.
Matz says in [ruby-core:83954] that Data should be an alias of Object.
Because rb_cData has not been deprecated, let us deprecate the constant
to make it a C-level synonym of rb_cObject.
This adds rb_category_compile_warn in order to emit compiler warnings
with categories. Note that Ripper currently ignores the category
for these warnings, but by default it ignores the warnings completely,
so this shouldn't matter.
Since we decided to only allowing specific warning categories,
there is no reason to have an API that accepts a general string,
as it is more error-prone. Switch to only allowing the specific
warning categories.
As rb_category_warn{,ing} are public API, this requires making
rb_warning_category_t public API as well.
This adds the following C-API functions that can be used to emit
warnings with categories included:
```c
void rb_category_warn(const char *, const char*, ...)
void rb_category_warning(const char*, const char*, ...)
```
Internally in error.c, there is an rb_warn_category function
that will call Warning.warn with the string and the category
keyword if it doesn't have an arity of 1, and will call
Warning.warn with just the string if it has an arity of 1.
This refactors the rb_warn_deprecated{,_to_remove} functions
to use rb_warn_category.
This makes Kernel#warn accept a category keyword and pass it
to Warning.warn, so that Ruby methods can more easily emit
warnings with categories. rb_warn_category makes sure that
the passed category is a already defined category symbol
before calling Warning.warn.
The only currently defined warning category is :deprecated,
since that is what is already used. More categories can be
added in later commits.
In general accepting arbitrary keywords is a bad idea unless you are
delegating keywords or acting on arbitrary keywords. In this case,
the category keyword is ignored, and it's less error prone to not
ignore all keywords.
A backtrace object in an exception had never supported marshalling
correctly: `Marshal.load(Marshal.dump(exc)).backtrace_locations` dumped
core.
An Exception object has two hidden instance varibles for backtrace data:
one is "bt", which has an Array of Strings, and the other is
"bt_locations", which has an Array of Thread::Backtrace::Locations.
However, Exception's dump outputs data so that the two variables are the
same Array of Strings. Thus, "bt_locations" had a wrong-type object.
For the compatibility, it is difficult to change the dump format. This
changeset fixes the issue by ignoring data for "bt_locations" at the
loading phase if "bt_locations" refers to the same object as "bt".
Future work: Exception's dump should output "bt_locations"
appropriately.
https://bugs.ruby-lang.org/issues/17150
PR https://github.com/ruby/ruby/pull/3418 added a category to
`rb_warn_deprecated_to_remove` but not to `rb_warn_deprecated`. This
adds the same code to `rb_warn_deprecated` so that those warnings also
get a category.
This change also adds tests for `rb_warn_deprecated` and updates the
tests for `rb_warn_deprecated_to_remove` to have clearer names.
I've fixed the call to `rb_method_entry` as we need to be using the
instance method, not singleton.
Feature: https://bugs.ruby-lang.org/issues/17122
This change adds a `category` kwarg to make it easier to monkey patch
`Warning.warn`. Warnings already have a category, but that warning isn't
exposed. This implements a way to get the category so that warnings with
a specific category, like deprecated, can be treated differently than
other warnings in an application.
The change here does an arity check on the method to support backwards
compatibility for applications that may already have a warning monkey
patch.
For our usecase we want to `raise` for deprecation warnings in order to
get the behavior for the next Ruby version. For example, now that we
fixed all our warnings and deployed Ruby 2.7 to production, we want to
be able to have deprecation warnings behave like they would in 3.0: raise
an error. For other warnings, like uninialized constants, that behavior
won't be removed from Ruby in the next version, so we don't need to
raise errors.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Not every compilers understand that rb_raise does not return. When a
function does not end with a return statement, such compilers can issue
warnings. We would better tell them about reachabilities.
This limit was introduced on Nov 20 1996
in 554b989ba1
Apparently to protect from a buffer overflow:
* eval.c (f_missing): オブジェクトの文字列表現が長すぎる時バッファ
を書き潰していた
However I tested that path with very large strings
and it works fine.
Saves comitters' daily life by avoid #include-ing everything from
internal.h to make each file do so instead. This would significantly
speed up incremental builds.
We take the following inclusion order in this changeset:
1. "ruby/config.h", where _GNU_SOURCE is defined (must be the very
first thing among everything).
2. RUBY_EXTCONF_H if any.
3. Standard C headers, sorted alphabetically.
4. Other system headers, maybe guarded by #ifdef
5. Everything else, sorted alphabetically.
Exceptions are those win32-related headers, which tend not be self-
containing (headers have inclusion order dependencies).
These functions are used from within a compilation unit so we can
make them static, for better binary size. This changeset reduces
the size of generated ruby binary from 26,590,128 bytes to
26,584,472 bytes on my macihne.
This removes the related tests, and puts the related specs behind
version guards. This affects all code in lib, including some
libraries that may want to support older versions of Ruby.
This removes the security features added by $SAFE = 1, and warns for access
or modification of $SAFE from Ruby-level, as well as warning when calling
all public C functions related to $SAFE.
This modifies some internal functions that took a safe level argument
to no longer take the argument.
rb_require_safe now warns, rb_require_string has been added as a
version that takes a VALUE and does not warn.
One public C function that still takes a safe level argument and that
this doesn't warn for is rb_eval_cmd. We may want to consider
adding an alternative method that does not take a safe level argument,
and warn for rb_eval_cmd.
Looking at the list of symbols inside of libruby-static.a, I found
hundreds of functions that are defined, but used from nowhere.
There can be reasons for each of them (e.g. some functions are
specific to some platform, some are useful when debugging, etc).
However it seems the functions deleted here exist for no reason.
This changeset reduces the size of ruby binary from 26,671,456
bytes to 26,592,864 bytes on my machine.
Suggested by ko1. rb_fatal requires GVL so just in case one lacks,
print that information and let the process die. As commented,
we cannot print the given messages on such situations.
Requested by ko1 that ability of calling rb_raise from anywhere
outside of GVL is "too much". Give up that part, move the GVL
aquisition routine into gc.c, and make our new gc_raise().
Now that allocation routines like ALLOC_N() can raise exceptions
on integer overflows. This is a problem when the calling thread
has no GVL. Memory allocations has been allowed without it, but
can still fail.
Let's just relax rb_raise's restriction so that we can call it
with or without GVL. With GVL the behaviour is unchanged. With
no GVL, wait for it.
Also, integer overflows can theoretically occur during GC when
we expand the object space. We cannot do so much then. Call
rb_memerror and let that routine abort the process.
On Android, a signal handler that is not SIG_DFL is set by default for
SIGSEGV. Ruby's install_sighandler inserts Ruby's handler only when the
signal has no handler, so it does not insert Ruby's SEGV report handler,
which caused some test failures.
This changeset forces to install Ruby's handler for some fatal signals
(sigbus, sigsegv, and sigill). They keep the original handlers, and
call them when the interpreter receives the signals.
Just refactoring.
The name "rb_bug_context" is completely unclear for me.
(Can you see that "context" means "machine register context"?)
The context is available only when a fatal signal (sigbus, sigsegv, or
sigill) is received; in fact, the function is used only for fatal
signals. So, I think the name should be changed.
Cfuncs that use rb_scan_args with the : entry suffer similar keyword
argument separation issues that Ruby methods suffer if the cfuncs
accept optional or variable arguments.
This makes the following changes to : handling.
* Treats as **kw, prompting keyword argument separation warnings
if called with a positional hash.
* Do not look for an option hash if empty keywords are provided.
For backwards compatibility, treat an empty keyword splat as a empty
mandatory positional hash argument, but emit a a warning, as this
behavior will be removed in Ruby 3. The argument number check
needs to be moved lower so it can correctly handle an empty
positional argument being added.
* If the last argument is nil and it is necessary to treat it as an option
hash in order to make sure all arguments are processed, continue to
treat the last argument as the option hash. Emit a warning in this case,
as this behavior will be removed in Ruby 3.
* If splitting the keyword hash into two hashes, issue a warning, as we
will not be splitting hashes in Ruby 3.
* If the keyword argument is required to fill a mandatory positional
argument, continue to do so, but emit a warning as this behavior will
be going away in Ruby 3.
* If keyword arguments are provided and the last argument is not a hash,
that indicates something wrong. This can happen if a cfunc is calling
rb_scan_args multiple times, and providing arguments that were not
passed to it from Ruby. Callers need to switch to the new
rb_scan_args_kw function, which allows passing of whether keywords
were provided.
This commit fixes all warnings caused by the changes above.
It switches some function calls to *_kw versions with appropriate
kw_splat flags. If delegating arguments, RB_PASS_CALLED_KEYWORDS
is used. If creating new arguments, RB_PASS_KEYWORDS is used if
the last argument is a hash to be treated as keywords.
In open_key_args in io.c, use rb_scan_args_kw.
In this case, the arguments provided come from another C
function, not Ruby. The last argument may or may not be a hash,
so we can't set keyword argument mode. However, if it is a
hash, we don't want to warn when treating it as keywords.
In Ruby files, make sure to appropriately use keyword splats
or literal keywords when calling Cfuncs that now issue keyword
argument separation warnings through rb_scan_args. Also, make
sure not to pass nil in place of an option hash.
Work around Kernel#warn warnings due to problems in the Rubygems
override of the method. There is an open pull request to fix
these issues in Rubygems, but part of the Rubygems tests for
their override fail on ruby-head due to rb_scan_args not
recognizing empty keyword splats, which this commit fixes.
Implementation wise, adding rb_scan_args_kw is kind of a pain,
because rb_scan_args takes a variable number of arguments.
In order to not duplicate all the code, the function internals need
to be split into two functions taking a va_list, and to avoid passing
in a ton of arguments, a single struct argument is used to handle
the variables previously local to the function.
`rb_bug()` is called at critical bug, MRI can't run anymore.
To make debug easy, this patch introduces RUBY_ON_BUG environment
variable to specify the process which is called with pid.
[Feature #16090] [GH #2331]
RUBY_ON_BUG='gdb -p' ruby xxx.rb
In this case, if ruby interpreter causes critical bug, and call
rb_bug(), then "gdb -p [PID]' is called by system(3). You can
debug on invoked gdb.
This feature is limited on RUBY_DEVEL build.
Exception#backtrace and Exception#backtrace_locations can both be nil if
not set. The former can be set via `Exception#set_backtrace`, but the
later is only ever set at runtime via `setup_backtrace`.
You can rescue it:
f = ObjectSpace.each_object(Class){|c| break c if c.name == 'fatal'}
begin
raise f
rescue f
2
end # => 2
It's not a good idea to rescue fatal exceptions you didn't generate
yourself, though.
Fixes [Bug #10691]
FrozenError#receiver was added recently for getting the related
object programmatically. However, there are cases where FrozenError
is raised and not handled, and in those cases the resulting error
messages lack detail, which makes debugging the error more difficult,
especially in cases where the error is not easily reproducible.
This includes the inspect value of the frozen object in FrozenError
messages, which should make debugging simpler.
Similar to NameError#receiver, this returns the object on which
the modification was attempted. This is useful as it can pinpoint
exactly what is frozen. In many cases when a FrozenError is
raised, you cannot determine from the context which object is
frozen that you attempted to modify.
Users of the current rb_error_frozen C function will have to switch
to using rb_error_frozen_object or the new rb_frozen_error_raise
in order to set the receiver of the FrozenError.
To allow the receiver to be set from Ruby, support an optional
second argument to FrozenError#initialize.
Implements [Feature #15751]
Kazuhiro NISHIYAMA
Nobuyoshi Nakada
Adam Daniels
S-H-GAMELINKS
Kenichi Kamiya
Garen Torikian
xtkoba (Tee KOBAYASHI)
Kazuki Tsujimoto
卜部昌平
Jeremy Evans
Alan Wu
Takashi Kokubun
Benoit Daloze
Yusuke Endoh
eileencodes
Jean Boussier
Koichi Sasada
zverok
Steven Harman
git
Luke Gruber
ktsj