- Meeting date: 2021-05-25
- Team members: Niko, Josh, Taylor, Felix
- Others: simulacrum, Mara
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
- Done: "Generators planning" lang-team#92
- Done: "May updates" lang-team#93
- Tomorrow: "Rust language "guiding principles"" lang-team#91
Link: #86
- Pending action item: Niko to make sure we have a lang team design note on eagerly drop #86
- Niko: started working on this. Will be done soon.
- No discussion needed.
Link: #62
Link: #63
Link: #69
Link: #71
Link: #76
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).
Link: rust-lang/rfcs#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.
Link: rust-lang/rust#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.
Link: rust-lang/rust#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
likelyby pointer, but then it doesn't hurt, right?
- It doesn't make much sense to invoke
- 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
Link: rust-lang/rfcs#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
- But this RFC in some sense codifies the relationship more clearly
- 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
- You can put an unsafe block inside the function but not have an unsafe on the impl
- 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/?andasync/awaitit seems quite reasonable to haveunsafe/trustedor similar for introduce and discharge. (Thoughunsafeisn't "carried" so it's not a perfect parallel.)
- 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
Link: rust-lang/rfcs#2632
- Sort of not-clearly blocked. Really old pending FCP (since April 2019) - rust-lang/rfcs#2632 (comment)
- May make sense to close this RFC, in favor of a fresh one given all the changes since then, at least to start a fresh thread.
Link: rust-lang/rust#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
Link: rust-lang/rust#83918
Link: rust-lang/rust#84039
Link: rust-lang/rust#84045
Link: rust-lang/rust#84297
Link: rust-lang/rust#84364
Link: rust-lang/rust#84414
Link: rust-lang/rust#84701
- r+'d
Link: rust-lang/rust#84838
Link: rust-lang/rust#84879
Link: rust-lang/rust#84988
Link: rust-lang/rust#85193
Link: rust-lang/rust#85194
Link: rust-lang/rust#85200
Link: rust-lang/rust#85263