[0] => [0, *, a]
#=> [0] length mismatch (given 1, expected 2+) (NoMatchingPatternError)
Ignore test failures of typeprof caused by this change for now.
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>
Jeremy Evans
Nobuyoshi Nakada
S.H
卜部昌平
Kazuki Tsujimoto
Kazuhiro NISHIYAMA
Adam Daniels
Kenichi Kamiya
Garen Torikian
xtkoba (Tee KOBAYASHI)
Alan Wu
Takashi Kokubun
Benoit Daloze
Yusuke Endoh
eileencodes