| title | tags |
|---|---|
Triage meeting 2022-02-08 |
triage-meeting |
- Meeting date: 2022-02-08
- Team members: nikomatsakis, pnkfelix, Scott, Josh
- Others: simulacrum, compiler-errors, Lokathor, Jane, Mara
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
- Feb 9th -- Backlog bonanza
- No doc required
- Feb 16th -- libs team sync / lang-team#130
- Mara/Josh to make doc
- Feb 23rd -- "Never type next steps" lang-team#141
- Mark/Niko to make doc
Any updates on compiler team horoscope relevant to this meeting? :)
- Planning a proposal around creating a "trait team"
- Goal: focused on impl + guidance on feasibility / design
- Will have a series of "deep dive" meetings that might be nice for lang folks to attend if desired
- where we investigate closely
Josh: Goal of having a team-full of people in that category of "sounds like a niko problem" would help.
- Probably has some regressions but hey
- Turned my notes from review into a rustc-dev-guide draft chapter
- rust-lang/rustc-dev-guide#1297
- hackmd
- explainer does contain a relatively detailed note on how it works
- read + feedback would be very appreciated, not clear if this will be accessible in this form
- it would hopefully move to the reference when we stabilize
Link: #102
Link: #116
Link: #118
Link: #125
Link: #126
Link: #129
Link: #135
Link: #139
Link: #143
- There has been extensive discussion on Zulip on this.
- Some notable items
- handling of private vs public fields
- how to make sure that this does not break non_exhaustive
- how people are using non_exhaustive precisely, and what they expect it means/covers
- Depends heavily on how we "desugar" functional-record-update
- scottmcm has posted a summary in the actual issue, it covers why scottmcm feels you can't "just accept" things
- niko: I think there's a good opportunity here to explain exactly what guarantees you are supposed to have, both with non-exhaustive and without
- josh: the distinction between whether you can add private/public fields didn't matter before, because there wasn't an operation you could do in one case and not the other
- niko: yes, and I think this brings out a distinction that's worth us trying to express
- josh: this is and has been ambiguous; we might need a different syntax to cover one or the other
- scottmcm: private fields are explicitly mentioned https://rust-lang.github.io/rfcs/2008-non-exhaustive.html#structs
- the implications are perhaps longer than were realized differently
- niko: yes, it's the implications I am most interested in and that I think we should make sure to document
- josh: yes, there are types that may have defaults, but doesn't mean you should elide them
- scottmcm: There's a lot of conversation about what FRU is and how it applies, and how people expect it to work
- josh: we merged the type-changing RFC right?
- scottmcm: yes
- josh: that plays into this question
- nikomatsakis: yes, I think there was an RFC about privacy as well
None.
None.
Check your boxes!
Link: rust-lang/rust#90957
- Still open! Needs a few more checkboxes!
- bstrie is making the change to specify which attributes work (and don't work)
Link: rust-lang/rust#92386
- still waiting for us to "make a call" regarding what we want
- has some blocking concerns that need to be addressed, which may require making some changes
Note: oh, it's tagged as waiting-on-author, but that doesn't cause it to be omitted from this list
simulacrum: it may be worth cancelling this FCP, it seems clear that the changes aren't going to happen in this PR, and re-evaluating in 3 or 4 weeks time whether the concerns have been addressed, some part of me feels we should cancel the FCP when it's ready to try again.
josh: you're proposed we close the PR and ask for a new one to be opened once the concerns are addressed?
simulacrum: yes. Essentially "no, this is not ready yet"
josh: seems reasonable, change will not be in this PR, while we can leave it open while other PRs get merged, we might also just want to pause it.
nikomatsakis: I'm in favor, but let's document the concerns in the tracking issue.
josh: worth documenting that we had enough checkboxes to get consensus, so folks can assume that if we do those named items, reasonable to expect that the next FCP will succeed.
simulacrum: I'll take an action item to type a comment, close the PR, and either filing or repurosing a tracking issue.
josh: my point is, sometimes people don't write out all their concerns so long as there is one, if folks have other objections beyond those currently registered, please do explicit list them so people know what to work on. Want to avoid whack-a-mole.
nikomatsakis: makes sense.
simulacrum: yes, though I don't think we can promise no future concerns will be raised.
josh: :thumbs-up:
"Check if enum from foreign crate has any non exhaustive variants when attempting a cast" rust#92744
Link: rust-lang/rust#92744
joshtriplett: awaiting a few check boxes
pnkfelix: this is waiting on a revised design, right? Hooked into the stuff about enums and reprs?
joshtriplett: I think this is independent, part of a decision we already made in a previous round, specifically that we want to not allow you to do an as cast on an enum from another crate, since that cast could stop working if you add variants or fields to the enum (as non-exhaustive is meant to permit).
nikomatsakis: I feel like this is a no-brainer and everyone in this meeting should check their box or ANSWER TO ME ;)
scottmcm: in particular this is not related to the question of empty parens or braces or whatever, because non-exhaustive allows adding entire fields, which has never been allowed
nikomatsakis: or new variants!
scottmcm: this is specifically about non-exhaustive on the variant
nikomatsakis: we should check the variant case
pnkfelix: deja vu, didn't we talk about this last time??
/me nikomatsakis makes up dialog
Link: rust-lang/rust#93628
scottmcm: I put a concern on this about rustfmt. Seems like a good conversation to have. I think I will remove my concern about rustfmt.
joshtriplett: I think Niko's concern about needing a stabiliztion report is still blocking. That said, the other concern about rustfmt, there are narrow cases where we would potentially block on rustfmt, but I don't think this is currently one. calebcartwright said that while they don't change the syntax of rustfmt once it's established, they consider it acceptable to define the syntax once. I do think we should avoid the chicken-and-egg problem. Worth discussing.
scottmcm: I'm a little surprised by that position. Not sure what makes it easier to break everyone's CI by adding formatting the first time, as opposed to only later when they decide on the official one?
simulacrum: The main reason is that, the way rustfmt works, you have some users locally developing on nightly. This is usually fine. But with formatting, if your nightly compiler locally is using rustfmt, and it has introduced a chance, you save the file, it changes stuff, and when you submit it to CI, that expects a different kind of formatting, and now you have to change your toolchain locally to use this project -- often a pain in the neck.
nikomatsakis: that makes sense, but how does that address the "no rule enforced" but then they added one?
simulacrum: when nothing is enforced, the stable CI will not complain, because it will be preserved.
joshtriplett: I see, I see. rustfmt will allow whatever you use, so it won't change your formatting, so CI won't see a diff and complain. At some point, we add something in rustfmt, and there's a one-time issue of matching that format.
to summarize:
- CI is formatting with version N, which doesn't care how let-else is formatted
- if you use nightly and it gains a way to format let-else, CI is still happy (because it doesn't care)
- when you change CI from N to N+1, you do have to be careful about new formatting rules that have been added
- but you also have that problem because lints and other things
- so this is a pre-existing scenario
In practice, many people pin to stable, so they do experience a problem, but that is also true for lints.
nikomatsakis: I think we should think about how to make upgrading less painful. I also think distinguishing "the language for this is stable, but it's not fully ready for use".
joshtriplett: I have some concerns, but yes
scottmcm: it seems hard to do for things that use CI
nikomatsakis: why? ok, let's talk later
joshtriplett: in practice anyway, there is a bit of a race between rustfmt and codebases actively adopting.
Link: rust-lang/rust#32408
Reminder: this is associated with constrained naked functions above.
Has enough checkboxes to go forward. Reminder to raise concerns.
Link: #126
- nikomatsakis will follow up on this, has some thoughts
Link: #135
None.
24 minutes, 7 items, 3 minutes per item! No! More! Niko can't do math!
Link: rust-lang/rust#93658
Allows you to use different code based on panic strategy (panic=unwind, panic=abort). Had this implementation in October 2 years ago. Available for a while, would be reasonable to stabilize.
simulacrum: Back when we first landed it, there were concerns about stability, likely misuse, might be use relinking those concerns and including them in a stabilization report as addressed.
joshtriplett: I can make a note that when this is discussed in the release notes we should remind people to avoid writing code that assumes there are only two panic strategies and that "not panic=unwind" means "panic=abort" and vice versa.
simulacrum: I think some of those concerns were about incompatibility.
nikomatsakis: I feel like that's already a thing...
simulacrum: not new concerns, portability lint, but they should be mentioned at the FCP start.
nikomatsakis: this also allows you to be more compatible, e.g. libtest relies on unwinding and conceivably you could use this flag to launch processes or be compatible in some other way.
joshtriplett: any final concerns before I start FCP?
nikomatsakis: DO IT
scottmcm: DO IT
Link: rust-lang/rust#47384
nikomatsakis: what's the deal here
joshtriplett: Apparently this bug is a regression causing some issues in the ecosystem
mara: an old issue that changes over time and gets slightly worse. People use statics to get stuff to the linker and hope that it gets preserved. Sometimes entire objects are dropped if you don't use anything from a module, depending on how things are distributed, which changes between compiler versions, codegen-units, etc. There were two crates from david tolnay, linkme and xxx, that permit you to "gather up" things like the test framework does. Those crates kept being buggy because of this issue. Workaround was codegen-units=1 but dtolnay archived and deprecated those crates because of issues.
(scottmcm: aside, I want distributed_slice in the language https://internals.rust-lang.org/t/from-life-before-main-to-common-life-in-main/16006/25?u=scottmcm)
nikomatsakis: what's the lang team call here?
mara: whether it should guarantee?
joshtriplett: I think the question is:
- Is it a language level guarantee that, if you write
#[used], that symbol will end up in the final binary? (And ditto#[no_mangle]?)
If that's not the case, then #[used] has remarkably little value. You might ask what use it has.
mara: it suppresses some lints. Even if answer is no, people will ask for a new attribute.
simulacrum: there are apparently two different semantics. We guarantee it makes it to the linker or we guarantee linker will emit it in the final binary. Makes it to the linker is plausible, but making it through the linker is hard-to-impossible with current platforms, at least according to the thread.
joshtriplett: Original issue opened here involved a custom linker script. In the face of that, we can make no guarantees. If you don't have a custom linker script, or you're not doing anything weird, can we guarantee it all the way through the linker?
nikomatsakis: this is kind of outside my detailed knowledge area, I would like to have a good place to settle these sorts of linker and low-level questions.
joshtriplett: I think there's a decision we can make. Do we define that #[used] carries something through to the final binary or do we decide that it doesn't (and people should add a new one)? Somebody commented a few days back saying that this is equivalent to what gcc's used does, and therefore they think rustc is behaving properly, and there's a separate attribute, called retain, that does what they want.
simulacrum: this is the compiler/linker distinction I was getting at, fwiw. Some linkers apparently don't support retain.
joshtriplett: We could say that #[used] does mean retain, and if people want the weaker thing, we could do that.
Mara: #[used] guarantees it gets into the object file, but it's not clear which one, and if it ends up in a file from which nothing is used, then it gets dropped. In gcc/clang it's much easier to tell which .o file it will wind up in.
Felix: We could solve the codegen-units interaction.
Mara: I think an important thing that's missing from that comment, Josh, is that Rust doesn't give you control.
Niko: This sounds like a bug to me, it sounds like we should guarantee that it gets you "up to the final linking step".
Lokathor: don't forget custom linker script.
Josh: See
pnkfelix: I agree, I just want to say that gcc/clang having 2 separate attributes to denote these slightly different things means we have to match their behavior. To me, #[used] historically has meant "try your best to get it through the compiler/linker", and if people want the more precise controls, #[used] should mean "We do our damndest to get it through", modulo linker scripts and what not.
joshtriplett: Agreed, making #[used] do what most people want would be good, but this comment to points out that there is a use-case for #[used] (in the gcc sense) and a concern that #[retain] is not supported by all toolchains, so it may not be viable to declare that "our used means retain all the way through linking".
pnkfelix: is it ignored?
joshtriplett: in best case, worst case it creates a miscompilation, so it is not as simple as "let's do the thing people want", because that may not be supported.
mara: I feel like the #[used] attribute is buggy in the case of multiple codegen-units, which can be fixed, and that adding something that is "used but not retain" is just a feature request.
mara: It's a but unclear what "do our best to make it to the linker means", e.g., if you don't use a crate at all, that seems fine, people are not surprised. but the main problem is if you add it to a modulo, and the module ends up in a separate .o file, that might disappear, so making sure it ends up in the final binary, even though the entire crate is not used, is more the retain problem and doesn't fall on the gcc used attribute either. Not even possible in some object formats and linkers.
scottmcm: what I heard that I definitely agree with is that the pieceo of this that is specific to "codegen units" is "just a bug" and doesn't need lang team consideration, under the "multiple cgu should work" requirement, and that can be solved without more conversation.
mara: yeah I think if that gets solved the rest of the conversation gets a lot simpler.
nikomatsakis: what I don't know is whether, on some platforms, the bug that affects #[used] also affects trying to merge together codegen units? I guess that's an impl problem that rustc would have to resolve.
mara: you would probably have to put used things into one CGU.
joshtriplett: I think it's a useful clarification to say that "not getting as far as the linker" is a regression that should be fixed, and this can be fixed orthogonally from extending used.
mara: I think that's right.
joshtriplett: mara, are you up to write the above as a summary?
mara: I don't know much about CGUs, I just know setting it to 1 fixes things, felix, maybe you're the right person?
pnkfelix, softly and with apparent lack of eagerness: ok
joshtriplett: I'll do it!
Link: rust-lang/rust#93203
mara: I want this stabilized! This RFC has been around for ages! Super nice! Recent addition to the stdlib!
Open question about whether the interface could be nicer. Some open questions about whether it could be nicer to capture things by copy in some cases instead of "by reference", don't know the details, the situation is relatively complicated. Probably too much for this meeting. Would need someone with a lot of knowledge to take a good look to take a good look and tell us if this change is realistic or what. I'm afraid it will get stuck for the whole year.
nikomatsakis: I will read it and give thoughts. I think I know what's going on here.
nikomatsakis volunteers to read and respond
Link: rust-lang/rust#92472
josh: we don't have time to go into detail, but people should look at this, we discussed in libs, I think it needs lang signoff, straightforward change that is reasonably explained in the thread.
Link: rust-lang/rust#81642