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

997b55a
Opened by Felix S Klock II at 2019-11-05 02:43:52

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.

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

    Niko Matsakis at 2016-07-28 21:52:58

  2. 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.

    Felix S Klock II at 2019-06-03 13:18:32

  3. 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, ());
}

    Niko Matsakis at 2019-06-06 18:47:30

  4. 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).

    Taylor Cramer at 2019-06-06 18:52:03

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

    Niko Matsakis at 2019-06-06 18:53:32

  6. @nikomatsakis yeah, sorry, to clarify: I don't think it's wrong to feature-gate call sites, I just don't think it's a serious bug to not feature-gate call sites.

    Taylor Cramer at 2019-06-06 19:00:24

  7. We discussed this on Thursday's language team meeting. The conclusion was that if @pnkfelix wants to make a PR to fix this then @nikomatsakis would be happy to accept it. :)

    Mazdak Farrokhzad at 2019-06-16 03:34:52