| title | tags |
|---|---|
Triage meeting 2022-03-22 |
triage-meeting |
- Meeting date: 2022-03-22
- Team members: nikomatsakis, pnkfelix, Josh, Taylor
- Others: Lokathor, David Barsky, skippy
- Action item scribe: pnkfelix
- Note-taker: nikomatsakis
- "Structural equality" lang-team#94
- "Never allow unwinding from Drop impls" lang-team#97
- "Dyn upcasting, safety considerations" lang-team#119
- "Const eval overview" lang-team#131
- "Lint policy" lang-team#132
- ""RPITIDT"" lang-team#144
nikomatsakis: Just thought people might find these things interesting
joshtriplett: Do we feel ready to make an FCP proposal for this?
joshtriplett: Would best way be a PR to lang-team repository with an FCP, and then an Inside Rust blog post?
joshtriplett: Or are there substantial concerns to raise before FCP?
nikomatsakis: maybe replace this page with the blog post :)
https://lang-team.rust-lang.org/initiatives/priorities.html
nikomatsakis: Or just delete that page in favor of the roadmap
pnkfelix: I basically trust the two of you to have drafted something that makes sense; I've skimmed it a few times since we had our last deeper discussion. Only real question is whether there is any value in having a sync meeting to discuss it, or just say "no, we'll either async review it". Some of the lang team members aren't present in this meeting so we can't get their voice into what I'm saying.
joshtriplett: Have 4/5 at the moment.
pnkfelix: Oh!
cramertj, sweetly: "Hi Felix"
pnkfelix: OK-- well, is there value in a forced reading? I'm fine with async acceptance.
joshtriplett: I think it is appropriate to have an FCP to make sure it's what we'd like to officially endorse. I appreciate the trust you are expressing but I think it's appropriate to get full team signoff.
nikomatsakis: Are you suggesting we should ensure all 5 boxes are checked?
joshtriplett: No, I'd just want to follow the normal RFC process and have no objections.
nikomatsakis: I'd rather not block on a synchronous meeting.
pnkfelix: I think you should put a date for when you want people to respond by, to try and get a forcing function.
joshtriplett: OK, I'll take the action item on that.
joshtriplett: Oh, also, there's a t-lang/roadmap-2024 stream for discussion here.
joshtriplett: Folks during rustfmt are finding themselves in the position of having to decide style. They'd prefer to have policy be made by a team. I think that makes sense. Calebcartwright is interested in working on the style team issues; I am as well. I was a member of the style team back in the day. I see a lot of value in having a dedicated team for this. Doesn't need to be a weekly meeting like it used to be -- seems like a good idea. Any objections? Where should it be chartered? Who else might be interested?
nikomatsakis: (a) good idea (b) lang (c) I have no idea
joshtriplett: I agree with lang since it's mostly focused on lang formatting. Jane, Mara, do you think this has libs implications?
yaahc: I think it's mostly lang. Libs implications in terms of how we use the features, but doesn't feel like it needs to be cross-team specifically.
joshtriplett: yeah, I was thinking mostly of who would approve the charter.
mara: 👍
joshtriplett: ok, we've settled (a) and (b), scottmcm, you had a hand up earlier?
hilarity around being muted ensues, scottmcm drops
joshtriplett: anybody on this call excited about being on the bikeshed style team?
lokathor: yeah, I'll do that
nikomatsakis: oh dear god no
joshtriplett: that's 3 (caleb, josh, lokathor --ed), sounds good.
Link: #102
Link: #125
joshtriplett: continued large and expansive discussion here on Zulip. Hoping that we will eventually get this sorted, but it kind of grew and mutated, now also an ongoing discussion about unsafe code guidelines, pointers, providence, CHERI, etc. CHERI of course is one of the platforms where pointers are 128 and size_t is not. That part of the discussion doesn't have to be resolved to settle the short term question of whether usize is always size_t. I think that could be done, possibly over an edition boundary, but it doesn't quite feel like the right time to reach a decision. I think we might have consensus amongst the team, not sure yet, but I'm tracking the zulip discussion.
Link: #139
Link: #143
nikomatsakis: what about this one?
joshtriplett: I think people want it, but I'm not sure if it's still live. Updated only about a month ago.
nikomatsakis: I can follow up with Jack and see if he's still interested in this.
"Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147
Link: #147
joshtriplett: I wanted to call attention the fact that this was seconded! Also skippy is here!
skippy: Hi!
joshtriplett: I think they've been working on adding this to the compiler, too.
skippy: Do have some questions about traits code.
joshtriplett: Getting questions answered before a full draft is not a bad thing -- I wonder if we might have a team for that --
nikomatsakis: Drop in #wg-traits if you like, but I'm surprised you're in that code...
skippy: Fn traits---making all that work--- pretty much melted my brain.
nikomatsakis: Oh dear.
Link: #151
Allows people to extract cases of ABIs into a macro. e.g.
extern foo!() {
}Looks like Niko has seconded.
nikomatsakis: One question is if we feel an RFC is needed. I think it could get by with a tracking issue, PR, and a write-up.
joshtriplett: Is this insta-stable?
nikomatsakis: No.
pnkfelix: there was some resistance from petrochenkov saying, in essence, that this is a heavy-weight option compared to the problem it's solving. I think they were just saying "why don't we just adopt some semantics that would make us compatible with what windows does". Want to convey that there is at least some resistance from someone.
joshtriplett: For context, windows has a bunch of ABIs (fastcall etc). On 64-bit windows, in order to make code for 32-bit windows capable of being recompiled, they effectively made all those calling conventions no-ops. There was a proposal that we do the same, allow parsing things like fastcall on 64-bit windows and just ignore it and pass it through like the windows compiler would. Versus doing this by selecting via macros.
pnkfelix: In particular, we already do that for fastcall, but thiscall is a special case for historical reasons, or maybe lack of historical reasons.
nikomatsakis: I agree that we should match behavior of the windows compiler if we can.
joshtriplett: They had a big pile of 32 bit code, we don't have that constraint, so it's not obvious whether we should do that.
Lokathor: I think that having Rust code binding to C code look like the C code. If C code is expected to discard it, Rust code should do that too.
joshtriplett: Yes, I wasn't saying we shouldn't do this, but I think we shouldn't necessarily treat it as automatic to do it just because C does. Don't want to set precedent that we make decisions motivated by C legacy code. If it's a decision for convenience of new code, we should consider that.
nikomatsakis: It doesn't feel like legacy code is the motivation so much as parity with C code.
cramertj: Isn't this "far away" from whether you should be able to use macros in ABI position?
pnkfelix: There may be other reasons to support this beyond this one use case.
joshtriplett: As a general rule I would want to support macros anywhere that we can.
nikomatsakis: yes-- I think my response to petrochenkov is "why not both".
joshtriplett: Yes, it's a valid concern, but if there are uses beyond this use case. There was a comment on Rustacean Station that was something we should pay attention to, "macros are a wonderful tool for language and library design, but there's something unusual about language shipping things in macro form; you own the language, you can make it better". I kind of agree with that. If we were adding this just to workaround not having a feature, maybe we should just make it better.
cramertj: To bring this back to the core question, what happens today if you try and do this, can you not write a macro there at all? There are other things you can put between extern and fn besides an ABI, right? I guess unsafe comes first?
pnkfelix: I think you have to put ABI after...? Well, I don't remember.
cramertj: Well, you can just say extern fn foo...
Lokathor: ...and it's implicitly C...
cramertj: ...so my question is, what if it generated things beyond the ABI string
pnkfelix: e.g. the entire fn string
cramertj: yes, or one of the other keywords (async, const, etc). I think I would not expect that it can generate some of the things from that position and not others.
Lokathor: true.
pnkfelix: yes. Question being raised then: is this proposal to permit just an ABI, or does it permit other things? Any keyword, whole function definition? Sounds like something that needs to be pinned down.
cramertj: That is my question. If you could have a macro invocation following extern, I'd like it to be at least somewhat intuitive what it could expand to. It's surprising to me if it can only generate an ABI string and nothing else.
pnkfelix: I had opposite reaction, to be honest.
cramertj: what would you expect from this?
foo!() fn()pnkfelix: arbitrary macro followed by fn ... probably a separate item
scottmcm: what seems different to me is that it's extern foo!(), which disambiguates it a little bit.
cramertj: I see, so the extern feels to you like it has an implicit precedence of capturing the thing that follows it. I don't have that intution, but I can believe that others do.
scottmcm: I'm not sure that I have that intuition, but that is what makes it different from other tokens.
pnkfelix: Question is whether you can have other things after extern besides ABI and fn -- if parser allows other things after extern, that does change the story.
cramertj: I think that it seems sort of unique to have extern foo!() "capture" the foo!().
scottmcm: Analogy: pub(macro!()) fn foo() might be fine even though macro_including_the_pub!() fn foo() isn't.
joshtriplett: Does this already work? If so, I think that'd be sufficient and preferable.
#[some_proc_macro_setting_extern_abi(...)]
fn xyz() {
...
}
nikomatsakis: yes, you can certainly do that
joshtriplett: ok, so if there's an established way to do this, then would it make sense to say "that is the solution rather than filling in a random token in this particular place". I'm feeling more sympathy for petrochenkov's position here.
nikomatsakis: this is sort of the "general answer", because you can always pull a macro out
joshtriplett: it's not always satisfying since a top-level parser transformer is more annoying, but for this particular case, it's placed in the exact place that ABI would go
joshtriplett: I do wish you could write attribute macros with macro rules.
nikomatsakis: I think cramertj convinced me that this isn't worth the trouble. That said, in general macros don't "pop out" from the thing you are parsing.
Lokathor: instead of this being a macro, why not some way to remap ABI strings?
nikomatsakis: but why?
Lokathor: solves this use case.
joshtriplett: feels like an impl detail that we used a string.
joshtriplett: Sounds like we're kind of reaching a consensus leaning towards "closing this".
joshtriplett: Objections to that consensus? Volunteer to write it up?
nikomatsakis: I'd write it up. (Lokathor, we could discuss that separately, but I generally think a proc macro is good enough for that.)
joshtriplett: side note but I want to be able to use a macro-rules macro as an attribute. It'd be nice if you didn't have to use proc-macros for that.
pnkfelix: yes, I don't think they'd be happy with proc macro, providing a 3P crate that just does it would be ok too.
None.
None.
Check your boxes!
Link: rust-lang/rfcs#2956
Link: rust-lang/rfcs#3191
Link: rust-lang/rfcs#3216
Link: rust-lang/rust#84414
Link: rust-lang/rust#92980
Link: rust-lang/rust#93628
Link: rust-lang/rust#94775
Link: rust-lang/rust#94927
Link: rust-lang/rust#94081
Link: #102
Link: #126
Link: #135
barsky: Is dtolnay involved in this?
nikomatsakis: I don't know! Just ping him!
[dbarsky messages dtolnay about this]
"Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147
Link: #147
Link: #150
Link: #151
None.
Link: rust-lang/reference#1163
joshtriplett: nikomatsakis said he likd this, seemed reasonable...
nikomatsakis: this seemed very minor. Not sure if it needs an FCP, seemed like a clarification.
joshtriplett: when we're expanding guarantees to include things we've assumed, I think it's reasonable to FCP. Not so heavy weight.
nikomatsakis: I learned something, in any case, I'd forgotten you could specify an alignment with padding.
Link: rust-lang/reference#1152
joshtriplett: This actually changes the statement of tuples having zero guarantees -- and a few other things.
nikomatsakis: I wonder how this compares to what we wrote up in the unsafe code guidelines. I should compare.
nikomatsakis: (sounds of document perusal ensue) https://rust-lang.github.io/unsafe-code-guidelines/
In general, an anonymous tuple type (T1..Tn) of arity N is laid out "as if" there were a corresponding tuple struct declared in libcore.
#[repr(Rust)] struct TupleN<P1..Pn:?Sized>(P1..Pn);...As discussed below, this generally means that the compiler is free to re-order field layout as it wishes....
nikomatsakis: I would like to see the UCG text move into the reference bit by bit.
Link: rust-lang/compiler-team#494
joshtriplett: This needs lang review. Primarily a libs thing--whatever generator type is needs to have clone support-- but OTOH this has implications for how generators act in the language as a language construct. Anyway we may to take a look.
nikomatsakis: tl;dr, we currently allow closures to be clone if their contents are clone, this would extend to generators, it seems fine to me, I think this should be FCP'd when it lands, I don't think we need to be sticklers around having a lang team proposal or anything.
nikomatsakis: we had an RFC for the closure case, this seems like a small extension to that.
joshtriplett: being consulted seems fine.
pnkfelix: has someone reviewed the Zulip thread? I see lcnr is being somewhat resistant, not sure why. Seems like they think it's ok now, but I'd want to know that somebody read it.
nikomatsakis: I'll write the comment.
Link: rust-lang/rust#93313
joshtriplett: Does someone know what this is about and what we want to do about the lang team question? This is accepting more code than we did before, hence the need for lang team approval.
(some discussion ensued)
nikomatsakis: Will tag T-lang and FCP
Link: rust-lang/rfcs#3216
Link: rust-lang/rust#93582
Link: rust-lang/rust#94927