T-lang meeting agenda
Attendance
- Team members: nikomatsakis, pnkfelix, josh
- Others: simulacrum, Mara
Meeting roles
- Action item scribe: simulacrum
- Note-taker: pnkfelix
Scheduled meetings
Needs minutes:
Action item review
Pending proposals
"MCP: Allowing the compiler to eagerly drop values" lang-team#86
Link: https://github.com/rust-lang/lang-team/issues/86
- discussed a bit last week
- no one steps forward to claim they had been keeping track over last week
- niko: probably useful and important, but not clear what best next step is, especially with no one offering to take lead
- niko: do we postpone and come back to it? Would like to see at least a design notes writeup
- josh: postponing sounds like reasonable step. Also should ask one of the proposers to write up design notes. Also good to summarize discussions about the impact of changing default vs solely adding an opt-in
- niko: good identify baby-steps. Adding an opt-in seems like something like that. Also, linting against potentially surprising temporary lifetimes. Even a lint saying "you should explicitly drop guards of this kind."
- niko: people should write up thoughts and propose small steps.
- niko: want to be in place where we have data and can argue for/against changing defaults.
Nominated RFCs
"add const-ub RFC" rfcs#3016
Link: https://github.com/rust-lang/rfcs/pull/3016
- Ralf responded to some feedback and updated the RFC, confirming pnkfelix's hypothesis as to the actual effects.
- RFC should be self-contained now
- What this RFC claims is 'all undetected UB has obvious semantics and we do those', but pnkfelix disputes that the semantics are 'obvious'
- niko: I thought the RFC was saying "this behavior remains UB" but saying that the set of behavior which remains UB is that which has obvious semantics. It's not that we guarantee those obvious semantics. It seems like the fundamental conflict is that this is a very complex message.
- cramertj: I still don't know who is allowed to rely on what behavior and where.
- cramertj: e.g. we're going to either throw an error or have the "obvious" semantics, but not actually define what that semantics is.
- cramertj: the advantage of providing this guarantee to users seems non-obvious.
- niko: would be good to drill a little on the thread, but not here. I know what the advantage is of detecting UB at compile-time versus at all times (namely compilation time and enabling optimizations on const code).
- cramertj: the plan here seems like it changed over time, based on comment history, based on what oli and ralf learned about what C++ is providing at compile-time today
- niko: Can we agree we're not arguing about what the code, but rather about how we sell it?
- mark: I don't see it that way. There are at least two options, e.g. whether we allow optimizations on the MIR.
- niko: but no one is arguing in favor of that
- cramertj: I argue in favor of NRVO optimized CTFE.
- niko: there are at least three variants: no optimizations, all optimizations, or third, some optimizations but not others. (and optimizations could end up masking UB)
- cramertj: [specific example elided]
- felix: is discussing on thread going to yield good feedback for ralf?
- niko: I expect further discussion to guide me through the three alternatives
- mark: we should tell ralf that there is not explicit alignment within the lang team. Specific comments are not saying "no"; its us trying to understand what's being proposed.
- josh: right, no one here is saying that we object to what this is doing in principle.
- niko: I might but cramertj gave good reasons against guaranteeing UB detection
- josh: okay, well, no one yet objected…
- cramertj: at this point i don't think additional clarifications are what I need. I think I just disagree with what the RFC is proposing. I prefer a world where UB during CTFE still gives the compiler freedom.
- josh: I thougt the RFC provides that; it says some UB can be detected, and some is not.
- felix: I don't think it gives full freedom for undetected UB, that was ralf's last point
- niko: the RFC also spells out specific set of UB that is guaranteed to be detected, which also might be in conflict with cramertj's desiderata (sp?).
"Change visibility scoping rules for macro_rules macros" rfcs#3067
Link: https://github.com/rust-lang/rfcs/pull/3067
- niko: I think we should just close this RFC at preset
- team: yes, it has that even.
Link: https://github.com/rust-lang/rfcs/pull/3086
- this is now in FCP, and josh gave libs team a heads up (16 minutes ago)
P-high issues on rust-lang/rust
"repr(C) is unsound on MSVC targets" rust#81996
Link: https://github.com/rust-lang/rust/issues/81996
- josh: no movement since previous summary
- josh: does not need owner from T-lang. Would be good to summarize that our understanding that X is the blocker
- niko: we wanted to have repr© match C compiler. But there is investigation as to whether that is possible or would break too much code (due to bindgen behavior or other code that likewise relies on current behavior). We would like data in that direction.
- josh: bindgen need not be showstopper, if there's some other way (or if we add such a way) for bindgen to get its desired behavior. (There is precedent here.) As long as we know that the code that has been generated is going to (mostly) still work.
- niko: Action Item for josh to write comment to above effect.
"fn() -> Out is a valid type for unsized types Out, and it implements FnOnce<(), Output = Out>" rust#82633
Link: https://github.com/rust-lang/rust/issues/82633
- niko: seems ungreat
- niko: we intentionally left space for arguments to be unsized types in order to allow future extention to language to allow that
- niko: there have been proposals to similarly allow for unsized return types
- niko: but nothing has hit paydirt
- niko: plausibly we could remove the
:Sized bound from FnOnce::Output. To write the bound today you must use FnOnce() -> R (so R will have a Sized bound).
- [discussion of whether there's some way (stable) code could be relying on the presence of that bound today]
- "just adding type Output: ?Sized does cause x.py check to break in lots of ways" –> yes, it would be expected to break unstable code (like the compiler/stdlib)
- felix: to be clear, I was assuming we would add a restricton, not generalize
- niko: I am musing about generalizing. It depends on what future we want to go.
- niko: We presumably are "getting something" today from the assumption that Output is Sized
- niko: it needs to be assigned to someone.
- niko: P-high for T-compiler, not P-critical.
- felix: you think adding restriction makes it harder to generalize in future?
- niko: that's my theory, but its not clear.
- niko: might require implied-bounds to actually be problematic.
- felix: We have path forward for adding restriction; esteban volunteered to do so
- niko: lets put up that PR and see what happens.
trait A { fn a() where Self: Sized; }
impl A for str {
fn a() where Self: Sized {
unsafe { std::hint::unreachable_unchecked() }
}
}
fn foo<F: FnOnce<()>>() where F::Output: A { F::Output::a() }
fn main() { foo::<fn() -> str>() }
Nominated PRs and issues on rust-lang/reference
"Define field, element" reference#933
Link: https://github.com/rust-lang/reference/issues/933
How do we want to handle terminology for accessing the values in tuples, tuple structs, and arrays?
- Keep the status quo of the reference: Use
field for alphabetical names and element for numerical names and array values. If we do this, we may want to update the error messages in rustc that say that e.g. 1 is a field of a tuple.
- Always call the nameable ones fields. So tuples and tuple structs would have fields
0, 1, etc. just like the error messages say. Arrays would still have elements though, because you cannot use a field or tuple index expression to access them.
- Always call elements fields. Arrays included.
- Something else entirely?
- felix: we can rule out case 3.
- josh: probably case 4 too
- josh: seems using "field" for structs and "element" for arrays is fine. But what do we think of tuples as? A struct with unnamed fields?
- Precedent: https://rust-lang.github.io/rfcs/1506-adt-kinds.html
- Scott to write comment
"Rename "Value expressions and place expressions" section to "Evaluation categories"" reference#972
Link: https://github.com/rust-lang/reference/issues/972
- niko: not enamored of "evaluation categories", sounds syntactic?
- josh: proposal isn't to rename "value expression" and "place expression" itself; its just to name the domain that collects them both?
- niko: so "expression categories"?
- niko: lets leave a comment on issue.
Nominated PRs and issues on rust-lang/rust
"[Edition vNext] Consider deprecating weird nesting of items" rust#65516
Link: https://github.com/rust-lang/rust/issues/65516
- niko: we decided not to do this in the current edition.
- niko: and its been approved for FCP close
- niko: so we can just unnominate it
- niko: scott did ask about what is path forward for 2024.
- niko: I will leave comment saying what path forward is for this (i.e. add a lint)
"Tracking issue for #![feature(const_precise_live_drops)]" rust#73255
Link: https://github.com/rust-lang/rust/issues/73255
- niko: nominated for stabilization by oli 3 days ago
- niko: idea is to have more precision, to avoid errors when something would not drop because it has actually been moved
- mark: did we get answer about whether this is adding a dependence on implementation details?
- niko: it shouldn't today. It might in the future.
- niko: namely, as long as this happens immediately after drop-elaboration, then we should be fine.
- mark: it feels to me like we should match dropck(/borrowck). Weird to have two separate rules.
- mark: i don't feel strongly.
- niko: I'll take a look and make an opinion.
"Stabilize or_patterns (RFC 2535, 2530, 2175)" rust#79278
Link: https://github.com/rust-lang/rust/pull/79278
- in FCP merge. 3 open checkboxes. Niko immediately checks off their box.
- niko: I do want to throw a concern to address that the rename of pat should be to pat2015, not pat2018, based on precedent elsewhere.
- josh: this is not seeking to stabilize those new names
- josh: so that concern need not block new or-patterns, just macros that want to use the new matchers
- mara: it would be bad though to stabilize new or-patterns without providing transition plan (via the new variants of pat)
- niko: give me an action item to talk to mark and work this out
"Include adjustments to allow unsizing coercions for raw slice pointers in receiver position" rust#82190
Link: https://github.com/rust-lang/rust/pull/82190
- niko: I may no memory of this. I may have volunteered to take action here. Let me review this and come back to the meeting.
"make unaligned_references future-incompat lint warn-by-default" rust#82525
Link: https://github.com/rust-lang/rust/pull/82525
- niko: context: we were making
&packed.field unsafe. But now we have a safe way to do it.
- niko: so proposal is to start warning on any use of
&packed.field expression
- [discussion of why this removed need for
unsafe]
- conclusion:
- today: there is a lint today that is silenced by using unsafe
- this PR: makes this a FCW lint
- niko: and recommends the use of
addr_of which is now stable
- we are in favor of this as the lang team
"fn() -> Out is a valid type for unsized types Out, and it implements FnOnce<(), Output = Out>" rust#82633
Link: https://github.com/rust-lang/rust/issues/82633
"Document panicking cases for integer division and remainder" rust#82683
Link: https://github.com/rust-lang/rust/pull/82683
"Turn old edition lint (anonymous-parameters) into warn-by-default on 2015" rust#82918
Link: https://github.com/rust-lang/rust/pull/82918
"Use const generics for stdarch intrinsics" rust#83167
Link: https://github.com/rust-lang/rust/issues/83167
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe