owned this note   changed 4 years ago  
Published Linked with GitHub

T-lang meeting agenda

  • Meeting date: 2021-05-25

Attendance

  • Team members: Niko, Josh, Taylor, Felix
  • Others: simulacrum, Mara

Meeting roles

  • Action item scribe: simulacrum
  • Note-taker: nikomatsakis

Scheduled meetings

Action item review

Pending lang team project proposals

"MCP: Allowing the compiler to eagerly drop values" lang-team#86

Link: https://github.com/rust-lang/lang-team/issues/86

PRs on the lang-team repo

Draft design notes

"Initial draft of copy ergonomics design note" lang-team#62

Link: https://github.com/rust-lang/lang-team/pull/62

"Autoref/autoderef for operators" lang-team#63

Link: https://github.com/rust-lang/lang-team/pull/63

"Auto trait design note" lang-team#69

Link: https://github.com/rust-lang/lang-team/pull/69

"Add design notes for function-type Default implementation discussion" lang-team#71

Link: https://github.com/rust-lang/lang-team/pull/71

"Add draft of variadic notes" lang-team#76

Link: https://github.com/rust-lang/lang-team/pull/76

Proposed FCPs

Check your boxes!

  • Mark deleted several from here - the ones needing discussion are nominated, so will be below. Several have outstanding action items (mostly on Niko).

"RFC: Add target configuration" rfcs#2991

Link: https://github.com/rust-lang/rfcs/pull/2991

  • Blocked on consideration of more ergonomic target configuration as outlined here
    • would be an alternative to permitting specification of explicit target, potentially seen as avoiding negative effects of overly-specific cfgs.

Active FCPs

"rustc: Allow safe #[target_feature] on wasm" rust#84988

Link: https://github.com/rust-lang/rust/pull/84988

  • Trailing comment by Ralf: We should ask for clarification of the LLVM spec that this is not UB at the LLVM level. Could end up like other LLVM UB but not Rust UB bugs; Ralf thinks this is likely a reasonable tradeoff to make.

P-critical issues

"ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297

Link: https://github.com/rust-lang/rust/issues/84297

  • With some intrinsics, the way they are implemented, you can't get an actual function pointer
    • That can cause breakage when something becomes an intrinsic where it used to be a wrapper
  • We can fix this by always making things wrappers around intrinsics, but this impacts codegen etc
  • Or we can make the compiler generate shims automatically

Example:








fn main() {
    let _unused = if true {
        core::ptr::copy::<i32>
    } else {
        core::ptr::copy_nonoverlapping::<i32>
    };
}
  • Niko: I think we should just get rid of intrinsics as a concept and have lang items, and then use eddyb's trick to generate shims (direct calls are special indirect calls make a function pointer):




#[lang(likely)]
fn likely(...) {
    likely(...)
}
  • There's a distinction that some functions (e.g., copy) make sense to invoke by pointer and some don't (e.g., likely).
    • It doesn't make much sense to invoke likely by pointer, but then it doesn't hurt, right?
  • Meeting summary:
    • Lang would prefer that functions act like functions, and hence that the compiler can generate wrappers.
    • Not our purview for whether this is fixed in the compiler or not.
    • Question: Can all intrinsics be represented with a fn pointer – notably not sure about SIMD?
    • Mark to leave comment

Nominated RFCs, PRs and issues

"RFC: Overconstraining and omitting unsafe in impls of unsafe trait methods" rfcs#2316

Link: https://github.com/rust-lang/rfcs/pull/2316

  • matklad requested real world examples
    • originally motivated by the future trait, but Pin made that unnecessary
  • Primarily blocked on concerns about learnability
    • (but also ~no checkboxes ticked)
  • Proposal to shift to trusted/unsafe model, perhaps.
  • Meaning of unsafe is very context dependent.
    • But this RFC in some sense codifies the relationship more clearly
      • It makes them unsafe to call and not unsafe to implement
  • How does this combine with requiring an unsafe block inside the method?
    • You can put an unsafe block inside the function but not have an unsafe on the impl
      • That will compile
    • But is this different from any other unsafe function?
    • cramertj: I find it weird to have to write unsafe when there is not specific condition to write
  • Niko: I'm fairly convinced this is not making the space worse, though I'm also convinced trusted could be useful
    • scott: +1 to the idea of splitting up the keywords better here. Would be nice even just to make it easier to say out loud without the confusion. And with try/? and async/await it seems quite reasonable to have unsafe/trusted or similar for introduce and discharge. (Though unsafe isn't "carried" so it's not a perfect parallel.)

"Calling methods on generic parameters of const fns" rfcs#2632

Link: https://github.com/rust-lang/rfcs/pull/2632

"Tracking issue for RFC 2523, #[cfg(version(..))]" rust#64796

Link: https://github.com/rust-lang/rust/issues/64796

  • Ongoing discussion of cfg(version(…)) stabilizing before cfg(accessible(…))
  • One possibility: implementing a subset of cfg(accessible) that requires the accessibility item be in std/core/alloc
    • cramertj: stdlib + rustc?
    • josh: it'd be nice if we had feature detection for the language, but right now cfg(version) is the only thing we have for that
      • we could use the names of feature gates but we dropped that from the earlier proposals due to opposition
      • I'd still like to see it, but less concerned about blocking cfg(version) on that
      • utility of cfg for language features is much lower because of the fact that we have to be able to parse the item body
        • mara: you can avoid it with an identity macro though
    • mara: people use versioning to check for const – that's not possible with cfg(accessible), right?
      • josh: that doesn't work now, is that an important use case?
      • mara: a lot of scripts use versioning for that (I can make myself const if my callees are const)
    • taylor: Feel like we should stabilize – already immediately useful. Crates can't use cfg(version) until it's in their MSRV window as is.
      • niko: +1, given that build.rs versioning is in active use, the utility of delaying seems low to me

"Stabilize "RangeFrom" patterns" rust#83918

Link: https://github.com/rust-lang/rust/pull/83918

"Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039

Link: https://github.com/rust-lang/rust/pull/84039

"Deny float matches" rust#84045

Link: https://github.com/rust-lang/rust/pull/84045

"ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297

Link: https://github.com/rust-lang/rust/issues/84297

"Add expr202x macro pattern" rust#84364

Link: https://github.com/rust-lang/rust/pull/84364

"Allow struct and enum to contain inner attrs" rust#84414

Link: https://github.com/rust-lang/rust/pull/84414

"stabilize member constraints" rust#84701

Link: https://github.com/rust-lang/rust/pull/84701

  • r+'d

"implement Default for all arrays" rust#84838

Link: https://github.com/rust-lang/rust/pull/84838

"add back support for inner attributes on non-block expressions?" rust#84879

Link: https://github.com/rust-lang/rust/issues/84879

"rustc: Allow safe #[target_feature] on wasm" rust#84988

Link: https://github.com/rust-lang/rust/pull/84988

"Re-add support for parsing (and pretty-printing) inner-attributes in match body" rust#85193

Link: https://github.com/rust-lang/rust/pull/85193

"Stabilize RFC 2345: Allow panicking in constants" rust#85194

Link: https://github.com/rust-lang/rust/issues/85194

"Ignore derived Clone and Debug implementations during dead code analysis" rust#85200

Link: https://github.com/rust-lang/rust/pull/85200

"Check for union field accesses in THIR unsafeck" rust#85263

Link: https://github.com/rust-lang/rust/pull/85263

Select a repo