Bug #16480: Ruby 2.7, C++, and rb_define_method compilation error

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin18]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN

[jasonroelofs (Jason Roelofs)]

I maintain the Rice library which provides constructs for exposing C++ libraries into Ruby. With Ruby 2.7.0 I've got a hard compilation failure that I'm not sure how to fix.[1]

Diving into this, I've found that rb_define_method, when compiled under C++, is now a macro that uses templates to choose the correct overload by the given arity. However, this seems to require a constexpr-compatible use of rb_define_method, making the API unavailable for more dynamic uses[1].

The PR that made these changes is here[3].

I've looked for ways to get around this macro change but have been unable to make anything work. Is there a way I've missed to directly call the underlying C API function or is this now simply not possible with Ruby 2.7.0?

[1] https://github.com/jasonroelofs/rice/issues/119
[2] https://github.com/jasonroelofs/rice/blob/master/rice/detail/method_data.cpp#L78
[3] https://github.com/ruby/ruby/pull/2461

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned
• Assignee set to nobu (Nobuyoshi Nakada)

It indeed seems to be a bug. For C extensions, that arity argument can be a variable. There is a fallback code. But for C++, there is no way to accept non-constexpr arities. This is a problem.

@nobu (Nobuyoshi Nakada) Can you provide us a workaround? Or revert, because there is no way to support the extension library?

[nobu (Nobuyoshi Nakada)]

Doesn't #undef rb_define_method in that file work?

[jasonroelofs (Jason Roelofs)]

nobu (Nobuyoshi Nakada) wrote:

Doesn't #undef rb_define_method in that file work?

Ah yes it looks like it does and thanks for putting together the PR.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed

The arities must be eventually compile-time constants for the nature.
I think this case is quite special, and it is resolved in that project.