Static proc objects defined as methods may be placed in 4-byte alignments in 32-bit environments.
This may be misinterpreted as an immediate value depending on the address.
Since C11 and C++11 have additional language features for byte alignment, corresponding compilers use them to define the `mrb_alignas()` macro.
For earlier compilers, they use their own extensions to define the `mrb_alignas()` macro.
GCC supports `__attribute__((aligned(alignment)))` since at least version 2.95.3 (1999).
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#IDX305
According to GPT-4, support was added in version 2.7 (1995).
It is not known which version of Visual C++ added support for `__declspec(align(n))`.
According to GPT-4, at least Visual C++ 6.0 (1998) seems to support it.
Also, the documentation of past Intel C/C++ compilers that support `__declspec(align(n))` makes reference to support with Visual C++ 4.2 (1996).
https://www.intel.com/content/dam/www/public/ijkk/jp/ja/documents/developer/ccomp40j.pdf
The purpose is to remove the `mid` field from the `mrb_cache_entry` structure.
The resulting RAM requirement for the method cache is reduced from 5 words per entry to 4 words per entry for 32-bit CPUs.
The relevant changes are as follows:
- Removed `MRB_USE_METHOD_T_STRUCT`.
The `mrb_method_t` type is now always defined as a structure.
- Include method IDs in `mrb_method_t`
Change the `flags` member to `uint32_t`.
The bitstring structure should be the same as the keys of the `mt` table in `class.c`.
I believe the impact on API compatibility with previous versions is minimal.
This will be a partial merge of #5317 with the following changes.
- Remove `iclass->iv_c` since `iclass->iv_c` is equivalent to `iclass->c`.
- `class_iv_ptr()` returns a single pointer instead of a double pointer.
If `Class#allocate` is prohibited, subclasses should also be implicitly prohibited.
```ruby
p Class.new(Struct).allocate.class
# => #<Class:0x82362ac00> by #6122
# => allocator undefined for #<Class:0x000000083a983220> (TypeError) by Ruby 3.2
```
Added `MRB_DEFINE_ALLOCATOR()` to allow subclasses to use `Class#allocate`.
Supplement to #6122.
The method introduced by #5979 causes a fault by swapping classes.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
zsh: segmentation fault (core dumped) bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
```
After applying this patch, a `TypeError` exception will be raised.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
trace (most recent call last):
[1] -e:1
-e:1:in method: allocation failure of Proc (TypeError)
```
However, if the `mrb_vtype` is the same object, the same care must still be taken as before.
```console
% bin/mruby -e 'Method = Binding; p method(:puts).eval("12345")'
trace (most recent call last):
[1] -e:1
-e:1:in eval: wrong argument type nil (expected Proc) (TypeError)
```
Since `Env` objects are shared by Blocks/Procs in the same context,
making multiple aliases in one context screws up with alias names.
New implementation uses alias bodies (Procs) to refer new names.
As a side effect, `__callee__` stop working correctly for aliases.
To fix this `__callee__` problem, we need to keep alias method names in
`callinfo`, which consumes more memory. We are wondering that is worth
the compatibility.
Calling `Class#allocate` with `UnboundMethod#bind_call` usually succeeds without problems.
If this behavior does not make us happy, we can now prohibit it with `MRB_SET_INSTANCE_TT(klass, MRB_TT_UNDEF)`.
At the same time, it applies to the `Binding`, `Complex`, `Data`, `Float`, `Integer`, `Method`, `Rational` and `UnboundMethod` classes.
dearblue