| title | tags |
|---|---|
Triage meeting 2022-02-01 |
triage-meeting |
- Meeting date: 2022-02-01
- Team members: Niko, Felix, Josh, Scott
- Others: compiler-errors, Lokathor, David Barsky, Jane, simulacrum
- Action item scribe: simulacrum
- Note-taker: nikomatsakis
- Tomorrow: planning meeting!
(Meeting attendees, feel free to add items here!)
- Discussion on t-lang Zulip
- current definition is (llvm asm) intersection (gnu AS)
- May want to add documentation on which directives are supported inside asm
- notably, macro directive seems pretty likely to be something we want to avoid
asm!will ship stable in next stable version- future compilers may (at least partially) parse and warn on such usage, but not necessary to stabilize.
- josh: No action needed here but wanted to ensure
- if somebody wrote up a document with what we intend to support
- if we saw that as a PR to the reference or the
asm!docs - would we be willing to merge?
- nikomatsakis: current status is that they're "just" accepted?
- josh: yes, and that doesn't change, this would be documentation
- lokathor: concern was that someone was working on an alternate backend that didn't support all these features (not based on llvm / gnu)
- josh: right
- More up to date but not yet complete:
- nikomatsakis to write up guidelines but in short
- create a tracking issue, tag with T-lang, C-tracking-issue
- assign to the liaison / owner
- if there is a repository, create the tracking issue on there; if not, on rust-lang/rust or rust-lang/lang-team is fine
- set the status appropriately
- nikomatsakis: Did want to raise the question of status updates -- we still haven't really built the infra to do this, just wanted to sync up on this
- simulacrum: in our last discussion we talked about tying this to triage meetings, but that didn't yet materialize
- josh: had a conversation with someone interested in contributing by process or coordination, I mentioned to them we could use help figuring out how to scale up status etc, and they seemed excited about doing that, was planning to setup a conversation between them, niko, and myself to talk about how that should look
- don't think anyone in this meeting is super excited about sending pings or building infra, so it'd be great to have help
"Return position impl trait in traits" / tmandry and nikomatsakis had some discussions about this.
trait Foo {
fn bar() -> impl Trait;
}
impl Foo for u32 {
fn bar() -> impl Trait;
}
impl Foo for i32 {
fn bar() -> String;
}If we know specifically which impl applies, you get the concrete type (if one is given).i32::bar() would return String and not an opaque type.
tmandry was drawing an RFC about this idea as a general principle:
- If the trait and impl are different, the impl is "specializing" the trait interface and when we know which impl applies, we should use that.
- Accepted an RFC along these lines already for
unsafe, this would generalize it.
- Accepted an RFC along these lines already for
josh: Is this effectively covariance?
niko: yes, you could think of it like that.
pnkfelix: would it permit impl Subtrait?
niko: yes.
josh: to be clear, if impl Foo for i32 still said -> impl Trait, it internally would be allowed to know it returns a String, right? So it's more for users of the trait.
niko: I think the impl trait with this notation is scoped to the function, not the entire impl, but we could do it either way.
josh: it seems like we would want the desugaring to be...
// if you write
impl Foo for i32 {
fn bar() -> impl Trait;
fn otherfunc() {
... bar() ... // this should get to know the concrete type
}
}
nikomatsakis: this is further in than I wanted to go, but you can use TAITs to get a lot of precision...
type Bar = impl Trait;
impl Foo for i32 {
fn bar() -> Bar;
fn otherfunc() {
... bar() ... // this should get to know the concrete type
}
}
scottmcm:
trait Trait {
fn foo() -> impl Debug;
}
impl Trait for Foo {
fn foo() -> i32 { 0 }
}
<Foo as Trait>::foo() // would this know the specific type?
pnkfelix: strawman syntax:
impl Foo for T {
pub(impl) type LocallyKnown = i32;
fn foo() -> LocallyKnown { ... }
fn otherfunc() { /* knowns LocallyKnown == i32 */ }
}
oh but this is essentially niko's TAIT example
Mark and I are having misgivings about ! because the rules are seeming more complex than we'd like, but the simple rules have concrete downsides.
scott: Does that mean that return would not have type ! but instead an uninferred inference variable?
niko: Not exactly sure, we'd have to answer some of those questions.
josh: upshot is having less special rules and being less automatic
mark: yes, less special case, I'll note that if there are use cases for ! special cases.
josh: design meeting?
mark: yes, I can file an issue.
josh: I would definitely like more context.
david: I was wondering if inline asm reduces pressure for the optimization benefits of never type?
mark: I don't think it's really got strong optimization benefits, certainly not over empty enums.
scott: layout wise, it's the same, but the main difference is that the compiler is a bit smarter around some things with never specifically, assuming you have the feature gate, you need more matches with no arms without the special never type. That said, details tbd, but some sort of "let's just cut it back to something simpler we can do", given that I know a lot of smart people have looked at this a lot, making it happen by simplifying the rules seems like a good idea.
josh: Another question for design meeting, to what extent can we be forwards compatible if we figure out ways to be more clever later?
-
e.g. having a single crate-wide implementation of
impl AsyncRuntimeorimpl Allocator -
wg-async looking at this
-
niko: I don't know of anyone actively looking into this, but I'm more interested in scoped capabilities as a route to solving this. It seems better to me to be non-global.
-
josh: I think there are tradeoffs between the global crate-wide version and scoped capabilities, would like to talk about those tradeoffs
-
josh: do you think the global version if completely consumed ?
-
niko: yes! well, maybe.
-
pnkfelix: there are probably things to consider, make sure all uses cases are covered.
Link: #139
josh: lots of discussion on Zulip, pnkfelix do you want to elaborate?
pnkfelix: I wanted this for contexts that tend to be a single file, doc blocks, playground-- it's hard to express multicrate examples in these contexts. I've seen people write system calls to generate and compile files.
pnkfelix: one thing I will note is that I claimed this could help solve the proc-macro phasing problem (how they need to be in a distinct crate), and people pointed out in the zulip discussion that there would be a whole host of problems associated with that, e.g. host vs target machine. So I take it back as a motivating example, but I still think there is motivation here.
One assertion was that it might help the efficiency of compilation problem by letting people migrate their existing code to multiple crates.
josh: Also the issue of interaction between this a macros / cfg. Can you generate an internal crate like this using a macro? etc
pnkfelix: in my head, this would occur before macro expansion. petrochenkov pointed out that we have no precedence for something like that.
josh: I'd expect a different syntax to ensure it gets parsed at the right time.
If this is primarily motivated by the playground or examples, next best alternative would be special-cased support in the playground or doc tests. Something that lets you make an external crate. That's an alternative to trade off against, right?
pnkfelix: yes, we could special purpose.
josh: e.g. playground could have a "+crate" button
pnkfelix: yes, that's a larger overhaul.
josh: sure, but we're trading off where to do the work (playground vs Rust).
nikomatsakis: There are other use cases, I think idiomatically lots of private impl crates is common, and there are things like the facade where you want coherence rules to stretch across.
Jane: they're have been proposals for this, right?
nikomatsakis: yes.
pnkfelix: c-reduce may be another example-- something that only operates on a single file. Many cases where having it in the language versus each tool having to support multiple files. At some point it stops making sense to have each tool support this scenario over and over.
mark: c-reduce does not support multiple crates.
david barsky: Something I'm seeing at work where this would help is a bazel-style build system. In a lot of cases, I would personally prefer to do my inner dev loop with cargo potentially. The way that projects are structured doesn't fit with cargo, but this might help, so I would register interest.
josh: to interrupt, is there any further discussion valuable to have in this live meeting, versus continuing on the Zulip thread?
(other items not discussed)
None.
None.
Check your boxes!
Link: rust-lang/rust#32408
Josh: Proposal here is to close the "unrestricted" naked functions in favor of "assembly only" naked functions. Just in need of three further checkboxes.
Link: rust-lang/rust#92386
Josh: Blocked waiting on us in terms of "are we prepared to do this". A few blocking concerns that we want to see made. Tagged as waiting-on-team, but I think it is actually waiting-on-impl, right?
Mark: Pretty sure this is blocked on the changes to the lint being made.
Link: rust-lang/rust#93082
Josh: I'd like to find the next steps here, for RPITIRPIT (return position impl trait in return position impl trait...). Do we want to close this FCP now because of the stack of things that need fixing?
Niko: I would rather see a fresh proposal with the narrower version, if we think that narrower version is worth pursuing.
Josh: Niko can you poke the proposer and get it redirected?
Niko: Yes, I will do that.
(Skipping over these.)
Link: #126
Link: #135
Link: rust-lang/rust#93378
Josh: I agree with Mara this should get fixed quickly.
Open PR - Don't allow {} to refer to implicit captures in format_args. #93394
Josh: this is tagged T-compiler. To the extent that there is lang consideration, shall we just respond and say "from a lang team perspective yes please fix this as quickly as possible".
Felix: Might be a good idea to look over the #93394 tests but yes I'm fine with that.
Scott: This is pretty clearly an accident.
Niko: Side note, I love this feature.
Scott: I used it to make URLs and it was so much easier than it had a right to be.
Link: rust-lang/rust#47384
Link: rust-lang/rust#81642
Link: rust-lang/rust#92285
Niko:
- Fixes rust-lang/rust#80800
trait Foo { type T }trait Bar: Foo<T = u32> { }dyn Bar<T = i32>
- Main question is do we require a warning period
- No impact on crater
- Any concerns about just landing the fix?
Scott: soundness fix with no crater impact sounds good to me.
Mark: I might ask for a comment that we can paste into release notes.
Niko: That sounds like a very reasonable ask.
Josh: Yes, please write the release notes snippet.
Action item for Niko: write up release-notes snippet
Michael Goulet: we haven't done a crater run for the more general case, so that might break, though I think the cases are correctly wrong.
Niko: Do we have a test?
Michael Goulet: there was a test that failed, because Any requires static. If you check the changes in the last day, you'll see the test fails.
Niko: I'll take a look, I'm glad we made the fix better though!
Felix: I'm guessing it would be difficult do a warning period?
Niko: painful, maybe possible. We could probably use the evaluation machinery. But it seems hard.
Josh: Any legitimate reason to use this? If anyone is depending on this, would have to be by accident?
Niko: It's gotta be a bug. Not the kind of type system bug where you said a reasonable thing that the type system isn't smart enough to handle; more like you said two inconsistent things.
Josh: Let's see if crater turns up anything broken.
Niko: If nothing else, always good to be able to ping crate authors and give them a heads up.
Link: rust-lang/rust#92472
"Check if enum from foreign crate has any non exhaustive variants when attempting a cast" rust#92744
Link: rust-lang/rust#92744
Scott: Looks like a PR for disallowing casting of non-exhaustive enums, since that makes non-exhaustive not work. There's a crater run. I hadn't looked into the errors, but the ones I just clicked on was a false failure.
Josh: So the issue here is effectively if an enum is field-less we would normally let you cast it, but if it is field-less but non-exhaustive, it may stop being fieldless in the future?
Scott: Correct. Issue is #91161.
Josh: Are we disallowing this for a variant that is not-exhaustive? A non-exhaustive enum? Both, right?
Felix: do you think that no-exhaustive is meant to cover adding both variants and payloads?
Scott: This specific issue the variant has no fields but because the variant
Niko: but the new variant you add might have a payload itself, like if you added C here:
#[non_exhaustive]
enum Foo {
A,
B,
C(u32) // if added later, breaks as casts
}Josh: Didn't we already decide to disallow casting for Variant {},? Do we allow #[non_exhaustive] Variant,, and is it not breaking to make that Variant { field: u32 } later?
Scott: I can't remember where that conversation landed.
Niko: We had a meeting but I can't remember what fell out from that.
Scott: My recollection was that this came up during some part of that discussion and I opened a bug about it.
Josh: Are we going to only make this change with crater?
Niko: I would want a warning period if there are a lot of affected crates, but I would want to make the change either way.
Josh: OK, starting an FCP seems like a good idea.
Niko: Plus one.
Josh: You can check my box. ✔️
Link: rust-lang/rust#93203
Josh: This is the kind of thing I'd love to see us process offline. There's an unresolved lang question for "could we do better on the API here". That's something we can try to evaluate offline. Effectively, libs is asking "Could lang offer us better alternatives that would mean we should defer stabilizing this API". I suspect the answer is "no we can't" but we should confirm that.
Link: rust-lang/rust#93378