---
title: Triage meeting 2021-07-20
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2021-07-20
## Attendance
* Team members: joshtriplett, pnkfelix, cramertj, scottmcm
* Others: simulacrum
## Meeting roles
* Action item scribe: simulacrum
* Note-taker: pnkfelix
## Scheduled meetings
- "Lang team process, part 2" [lang-team#104](https://github.com/rust-lang/lang-team/issues/104)
- "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
- pnkfelix to reach out to oli to confirm that oli will own write-up in time for meeting
## 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
### "negative impls integrated into coherence" lang-team#96
**Link:** https://github.com/rust-lang/lang-team/issues/96
### "Trait Upcasting" lang-team#98
**Link:** https://github.com/rust-lang/lang-team/issues/98
### "Discontinue meeting recordings" lang-team#100
**Link:** https://github.com/rust-lang/lang-team/issues/100
### "Deprecate target_vendor " lang-team#102
**Link:** https://github.com/rust-lang/lang-team/issues/102
## PRs on the lang-team repo
### "Initial draft of copy ergonomics design note" lang-team#62
**Link:** https://github.com/rust-lang/lang-team/pull/62
### "Autoref/autoderef for operators" lang-team#63
**Link:** https://github.com/rust-lang/lang-team/pull/63
### "Add draft of variadic notes" lang-team#76
**Link:** https://github.com/rust-lang/lang-team/pull/76
### "Mark mermaid.min.js as binary so it doesn't show up in grep" lang-team#109
**Link:** https://github.com/rust-lang/lang-team/pull/109
### "Minor initiatives tweak: "typically" need to prepare an RFC" lang-team#110
**Link:** https://github.com/rust-lang/lang-team/pull/110
## RFCs waiting to be merged
### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316
**Link:** https://github.com/rust-lang/rfcs/pull/2316
- Scott to merge
### "RFC: Supertrait item shadowing" rfcs#2845
**Link:** https://github.com/rust-lang/rfcs/pull/2845
- Taylor to merge
### "`#[derive(Default)]` on enums with a `#[default]` attribute" rfcs#3107
**Link:** https://github.com/rust-lang/rfcs/pull/3107
- Felix to merge
### "RFC: let-else statements" rfcs#3137
**Link:** https://github.com/rust-lang/rfcs/pull/3137
- Josh to merge
## Proposed FCPs
**Check your boxes!**
### "RFC: Add `target` configuration" rfcs#2991
**Link:** https://github.com/rust-lang/rfcs/pull/2991
### "RFC: let-else statements" rfcs#3137
**Link:** https://github.com/rust-lang/rfcs/pull/3137
### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796
**Link:** https://github.com/rust-lang/rust/issues/64796
## Active FCPs
### "Stabilize `arbitrary_enum_discriminant`" rust#86860
**Link:** https://github.com/rust-lang/rust/pull/86860
### "negative impls integrated into coherence" lang-team#96
**Link:** https://github.com/rust-lang/lang-team/issues/96
### "Trait Upcasting" lang-team#98
**Link:** https://github.com/rust-lang/lang-team/issues/98
### "Discontinue meeting recordings" lang-team#100
**Link:** https://github.com/rust-lang/lang-team/issues/100
## P-critical issues
None.
## Nominated RFCs, PRs and issues
### "Fix how allow/warn/deny/forbid `warnings` is handled" rust#85298
**Link:** https://github.com/rust-lang/rust/pull/85298
- Nominated label removed, addressed last week.
### "Allow limited transmuting between types involving type parameters" rust#86281
**Link:** https://github.com/rust-lang/rust/pull/86281
### "Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable" rust#86492
**Link:** https://github.com/rust-lang/rust/pull/86492
### "Fix autoborrowing when coercing to a mutable raw pointer" rust#86647
**Link:** https://github.com/rust-lang/rust/pull/86647
### "Allow reifying intrinsics to `fn` pointers." rust#86699
**Link:** https://github.com/rust-lang/rust/pull/86699
### "Allow labeled loops as value expressions for `break`" rust#87026
**Link:** https://github.com/rust-lang/rust/pull/87026
- Discussion about whether to *require* parens or *warn* suggesting parens
- Looks like shadowing labels is supported, but a warning:
```
warning: label name `'foo` shadows a label name that is already in scope
```
```rust=
let x = 'foo: loop { ... break 'foo loop { ... break 'foo expr; ... } ... };
let y = 'foo: loop { ... break 'foo: loop { ... break 'foo expr; ... } ... };
```
Also note:
* there's no #[allow(shadowed_label_names)] #31745
* name-based comparison in new label-shadowing check has likely hygiene issues. #24278
Action item: Josh to write up summary and stop tracking for T-lang (not pursuing a language change here)
### "Support `#[track_caller]` on closures and generators" rust#87064
**Link:** https://github.com/rust-lang/rust/pull/87064
### "Make `#[derive(A, B, ...)]` cfg-eval its input only for `A, B, ...` and stabilize `feature(macro_attributes_in_derive_output)`" rust#87220
**Link:** https://github.com/rust-lang/rust/pull/87220
### "Stabilize built-in attribute macro `#[cfg_eval]`" rust#87221
**Link:** https://github.com/rust-lang/rust/pull/87221
### "Clarify "string continue" for (byte) string literals" reference#1042
**Link:** https://github.com/rust-lang/reference/pull/1042
```rust=
let b = "foo\
bar";
let c = "foo\
bar";
dbg!((b,c));
```
```
[src/main.rs:6] (b, c) = (
"foobar",
"foo\u{a0} bar",
)
```
## Discussion Notes
### "Allow labeled loops as value expressions for `break`" rust#87026
**Link:** https://github.com/rust-lang/rust/pull/87026
* Subtle distinction ("ambiguity", but not formally) `break 'label: loop` vs `break 'label loop`. Josh would like parens to disambiguate.
* We see labelled loops so rarely that its not part of our collective instincts
* What is core motivation? => Parser gives nonsense today.
* Parser fix allows compiler to accept it.
* Or could fix parser to give warning.
* PR author identified a non-uniformity of behavior; but did not say that this was a crucial feature they needed.
* Improvement for parser feedback would be for it to advise developer to add parentheses.
* Not technically ambiguous, so is it bad for parser to always say "you must put parentheses in here"?
* Unlikely to compile if you forget the colon...
* Distinction between introducing a new label versus referencing a pre-existing one should tend to be clear.
* (We don't allow shadowing of loop labels today. Oh no wait, we do; there's just a warning.)
* There are several arguments for "computer *can* understand this" (without parentheses). But what is the argument, if any, for "the computer *should* understand this"?
* Today you cannot do `&'a EXPR'` as an EXPR, so dropping the colon to get `'a loop { ...}'` is not today a hazard. But it might be a hazard for the future.
* Does anyone present want to object to saying "We do not see the need to support this without parentheses. The compiler diagnostics can be improved to guide developers, but no langauge change is needed." (no one objects)
### "Clarify "string continue" for (byte) string literals" reference#1042
**Link:** https://github.com/rust-lang/reference/pull/1042
* Came up on Zulip. People were asking how `reference` things bubble up to lang team. (Answer is: Needs to be both nominated and marked as T-lang.)
* Summary: reference claims all whitespace on following line after `\` is ignored in a string literal. But the implementation *solely* ignores sequences formed from the characters {space, tab, newline, carriage-return}.
* Interesting consequence of above: multiple blank lines without `\` will be ignored.
* pnkfelix wants to see if that's tested in rustc test suite
* Skipping newlines might be surprising. Skipping spaces and tabs understandable.
* Current behavior is potentially surprising. We might want to change via an edition.
* Should we warn about the blank line skipping behavior? and even make it an error?
* Hard to find out if anyone is relying on it.
* Well, the warning will give us basis on crater run.
* Reasonable to go slow here: Warn, then decide if we want an error path, and if so, do future-compat warning cycle before error.
* Even if we are all agreed about current behavior being non-ideal, should this PR be blocked on adding the warning here?
* I.e. what should policy be about correcting reference with things that we are not sure are the ideal we are aiming for?
* ehuss has said we lean towards documenting exactly what rustc does (and rely on other people to identify cases that are bugs or undesirable behavior).
* and this has been the behavior of rustc for 10 years.
* we should tell reference team that we (the lang team) consider this behavior a little weird, so if there's a standard way of flagging that in the reference document, it should be applied here.
* scottmcm opened an issue about warning on things like nbsp on the line after the backslash: https://github.com/rust-lang/rust/issues/87318
### "Allow limited transmuting between types involving type parameters" rust#86281
**Link:** https://github.com/rust-lang/rust/pull/86281
* cases being added:
* sized with same size and repr(transparent), or
* arrays of *same type parameter* (or repr(transparent) wrappers thereof) with matching element count
* adding functionality like this to the whole language may be dangerous
* perhaps better to use the identified standard library methods, such as `array_assume_init`, rather than jump to `transmute`.
* this may be overlapping with questions that are part of the safe-transmute work.
* so, patch-work changes like this may be at odds with what the safe-transmute project is trying to do.
* i.e. there are primitive features that safer-transmute is adding that would be leverged here.
* Also: there are questions of visibility and coherence (that have also been raised w.r.t. safe-transmute work) that this raises.
### "Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable" rust#86492
**Link:** https://github.com/rust-lang/rust/pull/86492
* mark's recollection is that either this isn't worth any changes, and things should remain as is, or that functions should behave the same regardless of whether it is a top-level function or a method on an impl.
* josh recalls we settled on the latter
* colliding uses of no_mangle should yield linker errors, which seems accpetable for that scenario.
* mark will write up summary
### "Allow reifying intrinsics to `fn` pointers." rust#86699
**Link:** https://github.com/rust-lang/rust/pull/86699
* we believe compiler team has already said they are fine with this, so only question is whether lang team has any objection to allowing this
* What cases are there of intrinsics that don't behave like functions?
* there are some that don't make sense to *use* like functions, e.g. `likely`/`unlikely` have dynamic semantics of identity functions, but you would not use them for that.
* (and `likely`/`unlikely` are not stably exposed anyway)
* Niko seemed to have thoughts on what lang team should do with this.
* Josh will rfcbot
### "Support `#[track_caller]` on closures and generators" rust#87064
**Link:** https://github.com/rust-lang/rust/pull/87064
* piling on `feature(stmt_expr_attributes)` for gating might be concerning
* if we add `track_caller` to a closure and that changes the compiler-generated trait method, that will be problem for stabilizing `FnOnce` et al.
* We already support `#[track_caller]` with trait methods, so we just need to find right way to combine these things.
* (E.g. do we need to duplicate the `Fn*` traits? Or add new alternate methods to their new entry points?)
Sign in with Wallet
Connect another wallet