---
title: Triage meeting 2021-06-01
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-06-01

## Attendance

* Team members: Niko, Josh, Scott
* Others: Mara, simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: nikomatsakis

## Scheduled meetings

- Planning meeting tomorrow!

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

### "MCP: Allowing the compiler to eagerly drop values" lang-team#86

**Link:** https://github.com/rust-lang/lang-team/issues/86

* Niko [generated raw notes](https://hackmd.io/6tR_rMWeS1SGAnX9R_Bc8A), will try to coallesce

## PRs on the lang-team repo

Meta-discussion about open PRs.

* Question: Do these represent consensus?
* These don't represent consensus around a particular design (that would be an RFC)
* "Consensus" (or at least agreement) that they accurately represent the conversations
* Response should just be to add
* "Does everyone feel their points are represented?"
* Seems excessive. We will have this discussion later.
* Mark: I think having a lang team member look it over and say "seems all right" is good enough, they are ultimately a living document.
* Someone can always make a PR with more.
* Josh: my concern is that part of the point of this RFC is to to make sure positions don't get lost by the time an RFC comes up
* We've sometimes had years pass.
* Niko: Let's document the purpose ("these aim to capture design points, considerations, and don't represent consensus around a particular design")
* and then assign to a person to merge when they feel ready
* Mark: some of these have been open since Oct 2020!
* having them get merged quickly will be more beneficial than having them sit around
* Josh: may make sense to spend a bit of time in meeting
* Mark: Scratch proposal:
* I would file an issue to use a design meeting and spend some time this month to catch up
* Josh: I do see value in having a lang team member to review it (also not the author)
* Rough consensus:
* Steady state process is to assign a lang-team reviewer (not author) to read and bring to the meeting
* For the current state, we can use a design meeting to accelerate

## Proposed FCPs

**Check your boxes!**
### "Type-changing struct update syntax" rfcs#2528

**Link:** https://github.com/rust-lang/rfcs/pull/2528

* Blocked on Niko, basically ready to review
* Niko to resolve concern, we can work out the inference details during implementation

### "Calling methods on generic parameters of const fns" rfcs#2632

**Link:** https://github.com/rust-lang/rfcs/pull/2632

* Maybe related to const generics vision doc work
* Can't remember what we expected to do here...?
* Mark: I think I had suggested that we just close this and have the project group re-open it
* Josh: the ask may have evolved
* we should be abundantly clear that this is not a negative, it's discouraging to start a new thread
* Niko: I think it's oli? I can talk to him
* In some cases, those things are currently stabilized

### "RFC: Supertrait item shadowing" rfcs#2845

**Link:** https://github.com/rust-lang/rfcs/pull/2845

* Niko has a concern that comes down to feeling uncomfortable with the fact that the specific bounds we use will become significant versus the elaborated bounds
* I'm probably willing to resolve it
* Josh: You don't have to drop it, I'd like to know if there's a path forward

trait Super { type A; }
trait Sub: Super { type A; }
fn foo<T: Sub>() {
    T::A // <T as Sub>::A, ambiguity warning
}
fn foo<T: Sub + Super>() {
    T::A // ambiguity error
}

* Question:
* Is it an error or a warning if you create ambiguity?
* Answer:
* Yes, but it would change from "always error" (today) to "error if called"
* Niko: I will re-read the RFC today but I'm particularly ok with ambiguity errors as it's an "obviously ok" step forward, and we can potentially do more later
* I was a bit uncomfortable with `T: Sub` being distinct from `T: Sub + Super` because that's not something that something that is significant today
* (Although I think it may be the right design)
* Josh: To be clear, we're not changing inherent vs trait method resolution, right?
* All: Right
* Scott: Based on a quick read of the RFC, I think this is the conservative version that Niko said they were ok with
* Niko to resolve concern (already done!)

Directly from RFC (including the comment):

trait Super {
	fn foo(&self);
}

trait Sub: Super {
	fn foo(&self);

	fn bar(&self) {
		// Is and will continue to be an error
		self.foo();
	}
}

### "RFC: Add `target` configuration" rfcs#2991

**Link:** https://github.com/rust-lang/rfcs/pull/2991

* Niko has a [concern to add something to the alternatives](https://github.com/rust-lang/rfcs/pull/2991#issuecomment-720491222)
* Alternative `#[cfg(target(arch="aarch64", os="none"))]`
* Equivalent to `#[cfg(all(target_arch="aarch64", target_os="none"))]`
* Josh: I feel like the main reason to want this is to match wasm32-unknown-unknown because it has no proper std
* But that seems like a specific special case, adding this just for that doesn't seem worthwhile
* ehuss raised concerns that full target matching is actually an anti-pattern
* josh: I'd prefer the shorthand, which would also permit people to be less specific ("is this wasm")
* scott: why does wasm have std anyway?
* josh: it does have a useful subset of std, and wasi didn't exist at the time, so this seemed practical
* ideally they'd use nice portability to provide a *subset* of std, but that's not a thing right now
* scott: are we stuck with this because back compat?
* mara: probably yes. things are stubbed out and panic.
* mark: it's also not a tier 1 target, we'd have to phase it out carefully, but that's an option
* josh: we could, but wasm with no operating system *is* a thing a number of people use. The question is mostly whether it should have stubs or no functions.
* scott: I'm less interested in this feature if the main use case is "wasm32-unknown-unknown" and we're not a big fan of this
* josh: right, I'm not seeing people specifically request it for other targets
* josh: what process? should I raise a concern, cancel FCP?
* niko: this has been going on for a while, registering a concern is nice but I'm also ok canceling the FCP
* don't know what other people think
* could ultimately do `target(full = "...")` if we *really* wanted to enable the full string

### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796

**Link:** https://github.com/rust-lang/rust/issues/64796

* Currently stalled:
* Josh is still concerned that we don't have any *other* feature detection mechanism available.
* Continued discussion about how narrow it can be.
* Seems to be a proposal for making `cfg(accessible)` that just looks at std/core/alloc/proc_macro
* I get the impression that implementing that would fully unblock this
* Mostly implementation work at this stage
* Niko: I'm sure you're aware that people do this with build.rs-- how is that different?
* Josh: I feel it's sufficiently awkward with the current setup, but cfg(version) is "a line", it makes it substantially easier and will lead to a lot more use.
* Niko: I find that convincing enough to not try to overcome this block.
* Mark: Right now you can also use build.rs to do accessible-style detection.
* Josh: One further caveat, if this is discovered to be excessively hard to implement, I'm happy to drop my concern, let's not block on having the perfect thing, but I feel like the concrete discussion has zeroed in on something that is extremely implementable
* Action item to post an update and open an issue looking for mentors
* Josh to do that and ping `@rust-lang/compiler` to ask if anyone would be up to mentor

### "Stabilize RFC 2345: Allow panicking in constants" rust#85194

**Link:** https://github.com/rust-lang/rust/issues/85194

* 3/5 checkboxes, concern recently resolved
* so in FCP now!
* only question might be around panics, which currently produce a hard error
* summary: https://github.com/rust-lang/rust/issues/85194#issuecomment-843466857
* doesn't work at all in edition 2021
* The `panic!()` form in Edition 2021 creates a format arguments
* You have to use `panic_any()`, does that work?
* Mara: Not right now, but would be easy.
* Can we just use `panic_any` only?
* Josh: In the future, it'd be nice if you could handle at least the case with no function arguments
* Mara: there is a special case, can we make it a const fn?
* Mara: If we stabilize this before the edition happens, then there is code for which we have no migration lints
* We don't detect this case
* Niko: I just think we should hold off on stabilizing at the moment until we've had a chance to talk this out.
* Mara: We could make a `panic_const` function that takes a string and panics
* Scott: I kind of like that.
* Conclusion: Concern raised, discuss on thread!

### "Ignore derived Clone and Debug implementations during dead code analysis" rust#85200

**Link:** https://github.com/rust-lang/rust/pull/85200

* 2/5 checkboxes
* There was back and forth on whether to include other traits
* Conclusion: No.
* Niko: Bit of a balancing act. The code is not *actually* dead, so the question is "how likely is it to have fields that are there only to be part of being cloned or debugged"?
* In practice, from compiler at least, PartialOrd and friends generated a lot of false warnings.
* Josh: Clone is hard to see, Debug is more plausible, but this is a warning, so people can still use `_` or an allow. Is it an ok case to allow?
* Scott: I'm imagining we could add Hash to the list (if you're not using it for Eq...weird to use it for Hash...). But we can do that in the future.
* Action item (Josh executed during meeting):
* Post a comment confirming that we are signing off only on Clone + Debug
* Code review can confirm that
* Encourage checkboxes!

## Active FCPs
### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316

**Link:** https://github.com/rust-lang/rfcs/pull/2316

* Aaron [raised the concern](https://github.com/rust-lang/rfcs/pull/2316#issuecomment-851062597) that folks might forget the `unsafe` on the impl when in fact it *is* required.
* Niko: Seems possible but it's also possible any place you write unsafe code
* Scott: This is not a new concern, we talked about it a bunch, I spent some time but it ultimately seems the same as `Vec::set_len`
* Niko: Seems like another feature request for unsafe fields
* Mark: Even with unsafe fields, you can still mess things up.
* Josh: :+1:
* Action item: Scott to say "we considered that"

## P-critical issues
### "ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297

**Link:** https://github.com/rust-lang/rust/issues/84297

(Already discussed, I believe)

## Nominated RFCs, PRs and issues

### "Re-add support for parsing (and pretty-printing) inner-attributes in match body" rust#85193

**Link:** https://github.com/rust-lang/rust/pull/85193

* pnkfelix opened Re-add support for parsing (and pretty-printing) inner-attributes within body of a match.
* see also:
* "add back support for inner attributes on non-block expressions?" rust#84879
* "Allow struct and enum to contain inner attrs" rust#84414
* Niko: main concern was that it made the compiler slower, right?
* Mark: I think it had more to do with possible optimizations
* Scott: I'm not actually fond of supporting this conceptually, but as a "well there was breakage, let's fix that", it seems like the right thing to do
* Mark: Next step is probably a T-lang FCP
* Josh: doing it

### "Add `expr202x` macro pattern" rust#84364

**Link:** https://github.com/rust-lang/rust/pull/84364

* Pending action item:
* 2021-05-11: Felix to ask for more concrete grammar implications (from and to) on https://github.com/rust-lang/rust/pull/84364

### "Deny float matches" rust#84045

**Link:** https://github.com/rust-lang/rust/pull/84045

* Niko's proposal: design meeting on structural equality this month

### "Stabilize "RangeFrom" patterns" rust#83918

**Link:** https://github.com/rust-lang/rust/pull/83918

* bstrie opened up a Zulip thread -- did anyone read it?

### "rustc: Allow safe #[target_feature] on wasm" rust#84988

**Link:** https://github.com/rust-lang/rust/pull/84988

* FCP is complete
* Ralf had raised a concern about LLVM optimizations

---

### "implement `Default` for all arrays" rust#84838

**Link:** https://github.com/rust-lang/rust/pull/84838

* Niko wrote up the consideration, we have to decide what to do, but didn't we discuss this before?

### "Check for union field accesses in THIR unsafeck" rust#85263

**Link:** https://github.com/rust-lang/rust/pull/85263

* Niko to do a deep read as part of his review queue.

### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316

**Link:** https://github.com/rust-lang/rfcs/pull/2316

(see above)

### "Calling methods on generic parameters of const fns" rfcs#2632

**Link:** https://github.com/rust-lang/rfcs/pull/2632

(see above)

### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796

**Link:** https://github.com/rust-lang/rust/issues/64796

(see above)

### "Ignore derived Clone and Debug implementations during dead code analysis" rust#85200

**Link:** https://github.com/rust-lang/rust/pull/85200

(see above)

### "Allow struct and enum to contain inner attrs" rust#84414

**Link:** https://github.com/rust-lang/rust/pull/84414

(see above)

### "add back support for inner attributes on non-block expressions?" rust#84879

**Link:** https://github.com/rust-lang/rust/issues/84879

(see above)

### "Stabilize RFC 2345: Allow panicking in constants" rust#85194

**Link:** https://github.com/rust-lang/rust/issues/85194

### "Fix how allow/warn/deny/forbid `warnings` is handled" rust#85298

**Link:** https://github.com/rust-lang/rust/pull/85298