AC_PROG_CXX checks for several C++ compilers INCLUDING g++. When none
of them were found it sets the CXX variable to be g++. This doesn't
make any sense. Absense of g++ has already been made sure.
Because we don't want insanity (that's the whole reason we test the
environment using autoconf), we need to swipe such insane variable out.
Previously, when an object is first initialized, ROBJECT_EMBED isn't
set. This means that for brand new objects, ROBJECT_NUMIV(obj) is 0 and
ROBJECT_IV_INDEX_TBL(obj) is NULL.
Previously, this combination meant that the inline cache would never be
initialized when setting an ivar on an object for the first time since
iv_index_tbl was NULL, and if it were it would never be used because
ROBJECT_NUMIV was 0. Both cases always fell through to the generic
rb_ivar_set which would then set the ROBJECT_EMBED flag and initialize
the ivar array.
This commit changes rb_class_allocate_instance to set the ROBJECT_EMBED
flag on the object initially and to initialize all members of the
embedded array to Qundef. This allows the inline cache to be set
correctly on first use and to be used on future uses.
This moves rb_class_allocate_instance to gc.c, so that it has access to
newobj_of. This seems appropriate given that there are other allocating
methods in this file (ex. rb_data_object_wrap, rb_imemo_new).
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 method is explicitly documented to not access the filesystem,
and the only way to get the correct behavior for a case where the
filesystem's case sensitivity differs from the operating system
default would be to access the filesystem.
Fixes [Bug #15417]
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>
The previous attempt to fix this in
b87df1bf24 reversed the argument
order instead of just fixing the quote escaping.
From Takahiro Kambe.
Fixes [Bug #15178]
Ruby strings don't always have a null terminator, so we can't use
it as a regular C string. By reading only the first len bytes of
the Ruby string, we won't read past the end of the Ruby string.