`rust-call` call ABI is not feature gated at call-sites

[pnkfelix]

Note: This may be a feature, not a bug. But I wanted to make the point explicit.

If I make a crate named defs with this:

#![feature(unboxed_closures)]
pub extern "rust-call" fn foo(_: (), _: ()) { println!("defs::foo"); }

and then a bin crate uses with a dependency on defs and this for its main.rs:

extern crate defs;
fn main() {
    println!("Hello");
    defs::foo((), ());
    println!("world!");

}

Compiling the former obviously provides the feature gate it needs to define something with the rust-call ABI.

But compiling the latter does not require any feature gate, even though it is calling something via the rust-call ABI which is not stable.

This may be fine, since the point of origin is gated (apart from problems like #34900). But it seems worth discussion.

[nikomatsakis]

Conclusion: this seems like we ought to feature gate the call sites (but not a big deal ultimately).

[pnkfelix]

I want to fix this. The longer we leave holes like this open, the worst it will be when we fix it.

triage: P-high. Assigning to self.

[nikomatsakis]

The real danger would be if you could invoke rust-call things on stable. I think the main danger vector would be Fn::call , but the following is (separately) unstable for me, not sure how one would do it:

fn main() {
    let x = || ();
    Fn::call(&x, ());
}

[cramertj]

I'm confused as to why this is a problem. There's no stability hole here, since it's impossible to define functions with this ABI on stable. Just in the same way that it is possible to use a proc macro that uses #![feature(proc_macro_hygiene)] without using the feature gate yourself, or to use a function written using a library feature that you have not enabled in your own crate, I would not expect that callers of a function defined using an unstable ABI feature would need to use #![feature(...)].

If there are particular APIs we'd like to remain unstable to call directly (such as the Fn ones) then we should certainly have feature gates for those (and, to my knowledge, we do).

[nikomatsakis]

(Not to say we shouldn't require a feature gate at call sites, I dont' have a problem with that)