Feature gate extern fn methods

[Aatch]

Rendered

[nagisa]

SGTM.

[rphmeier]

This seems very reasonable, but I'd be interested in seeing the fallout. Are there a lot of bindings to C libraries which use this feature?

[nagisa]

I know we have received at least one bug report about this feature in conjunction with no_mangle once our symbol duplication detection has landed.

[RalfJung]

Doesn't this RFC effectively break all Rust crates that wrap C libraries, e.g. https://crates.io/crates/openssl-sys/ and https://crates.io/crates/libusb-sys/ and many more?

[remram44]

@RalfJung No it doesn't. This RFC only aim to feature-gate extern methods, not functions.

[RalfJung]

Oh, I see :)

[nikomatsakis]

@Aatch do you have an impl? if you can whip one up, I can do a crater run, feels like necessary data before we make a decision one way or the other. But I'm inclined to 👍 here.

[nrc]

Vaguely related, should rustfmt change extern to extern "C" or vice versa: rust-lang/rustfmt#451

[nrc]

And +1 for a crater run

[eddyb]

This is no longer necessary AFAIK, all methods should be compatible with all ABIs now.

[nikomatsakis]

Hear ye, hear ye! This RFC is now entering final comment period.

I should note that, personally, I'm inclined not to accept, based on @eddyb's comment.

[nikomatsakis]

After discussion in the @rust-lang/lang meeting today, we've decided not to accept this RFC. There doesn't seem to be any particular semantic concerns about allowing methods to have their own ABI, and the implementation is even working as far as we know, so retroactively feature gating is not necessary. Thanks @Aatch!