---
title: Triage meeting 2021-05-18
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-05-18

## Attendance

* Team members: nikomatsakis, Taylor, scott, Josh
* Others: simulacrum

## Meeting roles

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

## Scheduled meetings
- ~~"Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)~~
- Tomorrow: "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93)
- Niko posted requests for updates, many of which arrived
- Next week: "Rust language "guiding principles"" [lang-team#91](https://github.com/rust-lang/lang-team/issues/91)

## Action item review

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

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

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

* 2021-04-06: Niko to make sure we have a lang team design note on eagerly drop https://github.com/rust-lang/lang-team/issues/86

## Pending rfcbot FCPs

* Check [rfcbot](https://rfcbot.rs/)

## Nominated RFCs

No nominated RFCs this time.

### Lexical reservation RFC (edition dependent)

* Consistency with current behavior of `r#`:
* Original proposal was "put a space on either side" to avoid the reservation, but:
* `r# foo` currently fails to compile.
* What does this mean for `foo# bar`?
* This would then reserve additional syntactic space.
* Allowing this to hash means that you can write `foo# bar` and don't have to write `foo # bar` or `foo #bar`.
* No known examples where anybody cares.
* Only example people have raised is `f#"..."` which is a distinct thing from this question.
* Meeting consensus:
* Lexing error to have `foo# ` for consistency with `r#`
* Action item: scott to report meeting consensus to the thread.
* https://github.com/rust-lang/rust/issues/84979
* `proc_macro::TokenStream::from_str` takes a string and has no way to specify the edition
* currently uses the edition of the invocation site of the procedural macro
* cramertj/niko: decent choice, but the function is flawed
* would expect this to take a span as an argument -- i.e., this trait impl should not exist
* one problem in practice:
* macro invocation sometimes "redirects" and hence you would get the edition
* another alternative: make this behavior work across all editions
* impact: existing procedural macros that rely on `f"foo"` would be broken without migration
* crater run did terminate that `k#foo` will not break any existing code
* decision:
* ask matklad + petrochenkov to elaborate a bit more on the downsides of edition-dependent lexing
* how much more difficult
* are there fundamental aspects of the design that are interrupted
* scottmcm: if we don't do edition-dependent lexing, can we ever introduce new tokens?
* conclusion: that seems hard =)
* what has been tested?
* started with everything and found `f".."`, that's why we tested `k#foo`
* should check for other things like `ident#ident`, we don't necessarily have to deal with `f"..."` at this time

## P-high issues on rust-lang/rust

No new issues or major updates.

## Nominated PRs and issues on rust-lang/reference
No nominated items this time.

## Nominated PRs and issues on rust-lang/rust

### "Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic)" rust#51999

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

* Nomination removed but moved to [#85194](https://github.com/rust-lang/rust/issues/85194)
* Question:
* Should we have a way to specify a constant whose value is not yet known?
* e.g., `const FOO: T = todo!();`
* Josh: this could be useul, maybe it wants its own feature?
* Given the concern around catching panics, do we want a "force compilation error"?
* Maybe, but we don't have a concrete example yet.
* Use sys::exit!!
* scottmcm has an existing action item

### "Tracking issue for unsizing casts in const fns" rust#64992

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

* In FCP now, 3 days remaining (https://github.com/rust-lang/rust/pull/85078)

### "Implement new lint for detecting buggy pointer-to-int casts" rust#81789

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

* [Mark summarized previous discussion](https://github.com/rust-lang/rust/pull/81789#issuecomment-841714319)
* [Libs thread opened, no clear conclusions](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20methods.20as.20more.20specific.20versions.20of.20.60as.60)
* Libs response:
* We are amenable to proposed concrete functions that serve specific conversion purposes.
* It would be fine to have them proposed individually.
* Also nice if somebody had a more comprehensive of "valuable uses of as" with proposed functions for all of them.
* Niko's opinion:
* This sounds like a project group with the goal of "deprecating as" (or "limiting as" to safer semantics).
* But we can do it bit by bit.
* Meeting consensus:
* Close the PR
* Suggest adding APIs to stdlib for these sorts of casts (convey the general approval of libs team)
* Ideally, do this comprehensively, but this is a libs team approval question
* Once APIs exist, lints to deprecate parts of `as` can be considered.
* Design note documenting the direction we would like to go.
* Josh to follow up.

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

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

* FCP complete but bstrie [left a comment](https://github.com/rust-lang/rust/pull/83918#issuecomment-837368851) about range patterns in slice position:
* The pattern `[..]` means "match any array"
* vs the pattern `[0..]` means "match an array with something >= 0 in it"
* slice notation:
* `[3, 4, 5, \[x @\] .., 6, 7]`
* bstrie proposes the following patterns should be an error:

match [0] {
        [0..10] => (),
        [..255] => (),
        [0..] => (),
        [..=10] => (),
}

* Josh: seems unlikely to be what you want. We could disallow them without parentheses.
* If what you mean is "match a single element array with values in this range" then use parens: `[(0..)]`
* Niko: feels like a lint to me.
* Josh: note this only applies to single element cases. If you write this:
* `[0.., 5.., 10..]`
* it's pretty clear what you want
* Meeting consensus:
* FCP stands but we would request a warn-by-default lint for the single element case.
* Open an E-mentor issue.
* Action item (Mark):
* Comment that we believe this would be sufficiently addressed by a warn-by-default lint and request bstrie open an issue.

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

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

* Motivation:
* WASM target features are not understood by all WASM targets.
* However, they will not misinterpret them, they will simply *fail to load* the WASM code.
* Using WASM target features (when targeting WASM) is hence not *unsafe*, but it may block your code from loading.
* scott:
* People want this for non-WASM, isn't this a special case of target feature 1.1?
* josh:
* target feature 1.1 allows you to call AVX from a fn that already requires AVX
* but separately, there is "should you be able to call a fn that requires SSE from a platform that has SSE mandatory"
* niko: are we concerned about the fact that it is target specific, and we generally try to avoid target specific errors and things?
* mark: target feature is already relative to your target (no namespaceing, etc), so if you are using target-feature without cfg, you are probably doing something wrong
* scott: what happens if you use target feature SSE on x86-64?
* josh: assuming that exists, it should just be a no-op, because all x86_64 targets have SSE
* scott: ok, this is different from WASM because not all WASM engines will have these instructions
* another point: wasm prevents a lot of UB, but we still don't want to make everything safe (e.g., dangling pointers)
* niko: still feels like UB, even if the scope is somewhat narrower

### "Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039

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

### "Deny float matches" rust#84045

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

* Update: const generics group had a discussion today, likely to be a design meeting proposal

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

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

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

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

### "stabilize member constraints" rust#84701

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

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

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

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

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

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

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

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

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

Initial summary comment: https://github.com/rust-lang/rust/pull/85263#issuecomment-842549594