Skip to content

Latest commit

 

History

History
109 lines (86 loc) · 5.76 KB

2020-06-22.md

File metadata and controls

109 lines (86 loc) · 5.76 KB
Raw

T-Lang Meeting: Current meeting

Recording available

Action item

Agenda

Notes from meeting:

FFI-Unwind

  • Not inclined to revisit questions like keyword notation (at least Niko is not)
  • Would rather not have "system" mean unwind if "C" excludes unwinding, would want to have a consistent opt-in
  • Could we have a lint for #[unwind(allowed)] that warns if the ABI does not permit unwinding?
    • We are going to remove this attribute but it’ll require some sort of transition period as people are using it today (on nightly).
    • Ideal:
      • Make this imply the newer ABI
      • Warn and encourage folks to migrate to the newer ABI

Issue 72012

  • Soundness problem with target feature

  • Reviewed the various solutions proposed

    • Unsafe to reference without calling
      • this breaks existing code but is also a more complex fix to implement, somewhat “unnatural” to not be able to refactor foo() to let x = foo; x()

  • “Fast fix”

    • functions that declare “target feature” do not implement Fn and friends

  • Josh’s ideal alternative

    • it is “unsafe” for functions that declare “target feature” to implement Fn and friends
      • i.e., you can only use this implementation in an unsafe block
      • but this is not an option (today) because it is a concept that the language supports, it would be like an impl that is unsafe to use
    • or — it is only possible within a function that has the same target feature set
      • it’s ok that functions can escape in this case because you’ve already “demonstrated” that you are capable of supporting those target features
    • conceptually these are kind of “impls” with where clauses that test the environment (“am I

  • Observation:

    • you can kind of model the “preferred” solution using closures, but not quite, because closures aren’t allowed to use the target feature of their enclosing item (example)
      • answer is probably yes

  • Niko’s proposal:

    • Accept the PR that says fns with target-feature declared do not implement the Fn traits
    • Address the question of closures and what target features they have available, which also provides a workaround for the above case
    • If in the future we wish to do so, we can create some conditions under which fns with target-feature may implement the Fn traits (backwards compatibly), but it involves adding some new concepts to the trait system (e.g., impls usable only with a given target feature in scope, or unsafe impls).

    // Example of escaping:

    #[target_feature(enable="avx")] fn use_avx() -> Box<dyn Fn()> { let x: Box<dyn Fn()> = Box::new(also_use_avx); x }

    #[target_feature(enable="avx")] fn also_use_avx() { println!("Hello from AVX") }

    fn main() { let y = use_avx(); }

    //

    #[target_feature(enable="avx")] fn use_avx() -> Box<dyn Fn()> { }

    impl … { // For the type of use_avx #[target_feature(enable="avx")] fn as_fn(&self) → impl Fn(…); }

    fn main() { let y = unsafe { use_avx.as_fn() }; }

    #[target_feature(enable="avx")] fn another_avx() -> Box<dyn Fn()> { use_avx.as_fn() // no unsafe needed }