---
title: Triage meeting 2021-03-23
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-03-23

## Attendance

* Team members: Josh, Niko, Felix, Taylor
* Others:

## Meeting roles

* Action item scribe: pnkfelix
* Note-taker: nikomatsakis / pnkfelix

## Scheduled meetings
- (done) "RFC backlog bonanza recap" [lang-team#84](https://github.com/rust-lang/lang-team/issues/84)
- (this week) "lang team reorg: shepherds 4.0, triage update" [lang-team#85](https://github.com/rust-lang/lang-team/issues/85)
- (next week) "How to dismantle an `&Atomic` bomb." [lang-team#82](https://github.com/rust-lang/lang-team/issues/82)

## 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

* Much previous and async discussion
* Conclusion--
* actionable smaller steps and a design note
* would have to start with some form of opt-in

## Nominated RFCs

* None

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

### "repr(C) is unsound on MSVC targets" rust#81996
**Link:** https://github.com/rust-lang/rust/issues/81996

* Status: still waiting on further discussion
* For this to make substantial progress probably need someone in the community to pick up and run with it
* Need someone to volunteer to dig deeply in, or else maybe we would want to close/downgrade it
* Problem is specific to particular types used on MSVC, becomes an unfortunate trap (no obvious warning)
* One option would be to introduce more explicit editions such that there is "C-2015" and "C-2024" or whatever and "C" becomes "C-2015" by default in older editions
* We'd have to figure out the migration story, but it is specific to ZSTs with non-1 alignment
* Action item: Felix to reach out to folks at Microsoft.
* Want to downgrade to P-medium
* But we can keep it as I-unsound in that the code is not following our documented semantics (compatible with C compiler)
* Action item: cramertj to downgrade to P-medium
* Lint might be a good idea as a first step towards an edition (would want that anyway)

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

* None

## Nominated PRs and issues on rust-lang/rust
### "Tracking issue for RFC 2457, "Allow non-ASCII identifiers"" rust#55467

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

* [Stabilization report](https://hackmd.io/@nbw0Mih0RLieoV6JBAtI3Q/Byz09PM4u)
* Suggested path: fcp merge
* may want to hold off until we have lint levels defined in report
* No major discussion during meeting; people should review the "hopefully resolved questions" when deciding whether to check their box
* Action item: Josh to propose fcp merge

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

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

> @rust-lang/lang: this PR adds a new lint that triggers when a pointer is cast to a non-`usize` integer. The intention is to reduce easy-to-miss bugs like `u16::max as u32` (rather than `u16::MAX as u32`): additional motivation is described in #81686.
>
> At the moment, this lint is allow-by-default, but I suggest it makes sense to make it warn-by-default. If this seems reasonable, could someone start an FCP for the new lint?

* Josh asks about casting to `u64`
* Mark commented that he would prefer to see `as usize as u64`
* and there may be 128-bit portability features in the future
* Concern:
* `as usize as u64` creates a lot of noise for mythical platforms that people don't have access to
* very unlikely could would be truly portable, may lead to folks disabling the lint altogether or not doing the right thing
* If we wanted in the future to adopt 128-bit platforms, what could we do?
* we could make the lint warn in the future
* we could use an edition
* we could introduce a portability lint
* A kind of precedent being set here that we want the default lint levels to target "practical portability"
* cramertj feels like it is an instance of the general policy of avoiding false warnings for lints
* Josh: we have occasionally done crater runs for lints that would seem to have large impact or which could be extremely noisy
* Do we think this is likely and hence merits a crater run?
* Or would it be sufficiently valuable even if there is a lot of noise?
* Josh: the only likely case would be code designed exclusively for 32 bit platforms
* Josh was original person to propose u64 exception. Would prefer someone else to own the report of the lang team consensus.
* Action Item: cramertj volunteers to leave a comment to the above.

### "make unaligned_references future-incompat lint warn-by-default" rust#82525

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

* proposed by RalfJ 26 days ago.
* addr_of mechanism was not yet stable, but now it is. So this makes `&` on packed fields warn-by-default.
* we've discussed previously; what was outcome? What remains?
* we want to do this. Niko has action item already.

### "Turn old edition lint (anonymous-parameters) into warn-by-default on 2015" rust#82918

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

* policy question: used to accept code below. It is hard-error in edition ~~2021~~ 2018. But should we warn about it on past editions?
* We tend not to warn about things on past editions, unless we are planning to deprecate it in genereal
* But a reason to deviate from that policy here is that this syntax breaks third-party tools (IDEs, syn crate).
* So even though the rustc compiler can (and should) continue to accept (absent `deny(warnings)`), it is a good idea to it to tell users that they are creating problems for third-party tools

trait Foo {
    fn bar(u32); // => fn bar(_: u32);
}

* Josh: in this particular case I'd be fine with this modulo a few concerns.
* Felix: do we want an umbrella lint for "might break tools"?
* Josh: Our argument in the past was that this was accepted by accident.
* Niko: I don't think that's accurate, not that it matters that much. I think this syntax goes back to when Marijn first implemented traits.
* How widely used in this in existing code?
* If it becomes warn-by-default, how many warnings do we expect to see?
* This is a hard error in the 2018 edition already.
* This addresses Josh's concerns.
* Action item: Josh to own fcp merge

### "Use const generics for stdarch intrinsics" rust#83167

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

Background: std::arch has some architecture specific intrinsics. Some require compile-time constants because they are directly encoded in the instruction. This was implemented by having a "rustc-magic-special" attribute that requires the parameter to be a compile time constant:

#[rustc_args_required_const(2)]
pub unsafe fn _mm_shuffle_ps(a: __m128, b: __m128, mask: i32) -> __m128 {...}

Proposal is to change those intrinsics to accept a const generic:

#[rustc_legacy_const_generics(2)]
pub unsafe fn _mm_shuffle_ps<const mask: i32>(a: __m128, b: __m128) -> __m128 {

* These intrinsics are stable so we can't remove the old code
* (Are they widespread?)
* Therefore this will not simplify the compiler that much
* However, it is also generating "huge MIR"?
* The previous mechanism did, but the newer mechanism that uses const generics solves that regardless.
* We translate the older calls to the new style.
* Question at hand is whether to support this "inline" syntax in newer editions
* Note that the constants do not always appear at the end of the list:

#[rustc_legacy_const_generics(1)]
pub fn foo<const Y: usize>(x: usize, z: usize) -> [usize; 3] {
    [x, Y, z]
}

fn main() {
    assert_eq!(foo(0 + 0, 1 + 1, 2 + 2), [0, 2, 4]);
    assert_eq!(foo::<{1 + 1}>(0 + 0, 2 + 2), [0, 2, 4]);
}

* Syntax to invoke the intrinsic is different in rust than the intel architecture manual
* and sometimes it's in the middle of the list

* Niko notes that this almost feels like a feature request in the fullness of time, but wouldn't want to block anything on this of course

fn foo<const Y: usize>(x: usize, y: =Y, z: usize)

* Josh notes that you could use macros to make the argument order precisely matches
* some third party Rust crates already do this sort of thing
* In the Edition 2021 meeting, @m-ou-se mentioned that the libs team had this idea as a compromise:
* New edition only accepts proper rust syntax (2nd one)
* But produce a warning with a machine applicable fix from the 1st one
* SIMD working group is reasonably active and generally in favor of this proposal (is this true?)
* Mark: I would prefer the compiler continues to accept changing the order of the arguments rather than forcing end-users to think about it
* Mark: part of the goal with SIMD intrisics was to explicitly match the Intel notation
* saying we'll violate the naming conventions but force you to change parameter order and const generics feels ungreat
* Josh: suppose we did introduce macros with exactly the same name as the function
* you just have to add `!` and your code continues to compile, has the arguments in the correct order
* calls using the newer notation
* does anyone object to that being the proposed rewrite?
* `std::arch::__mm__foo!(x, y, z)`
* Advantage?
* you don't have something that rewrites syntax that isn't a macro
* Mark: if we were going back and redesigning, maybe, but is it worth it now?
* Felix: if I were trying to analyze my source code, at least with a macro, I would know to be on the look out for something surprising
* Josh: this can have an effect on code reordering tools which don't realize this isn't a legal refactoring
* Felix: but I wouldn't want to go to a macro if we might do what Niko was suggesting
* Josh: FWIW, the std-arch team has committed to the plan that future architectures will only use the newer syntax
* Niko:
* I'm not sure if that makes sense, but I'd like to give weight to what the people closest to the decision want
* I also think that we could hold off on deprecating until we know more surely whether we want to support something like the inline notation I gave above
* Crystallize the debate:
* we want the usage of SIMD intrinsics to match the intel specification as closely as we can
* we want a language with fewer, consistenly used mechanisms
* const generics and macros are both established mechanisms for this kind of constraint
* but we do have to support that in older code
* so the person who benefits is a user who has the privilege of writing Rust 2021+ code and thus doesn't have to use or know about older editions
* Who is affected by this
* Folks who are using these intrinsics
* Toolmakers who have to take this into account

* Only reason to make this change is if we believe people will adopt this syntax.
* Need evidence that people care about this so much that they want compiler to tell them to use the const-generic API form.
* We can always add a lint.
* Conclusion: Hesitant to force users in this direction without feedback from existing users saying they are actively in favor of const generics (or neutral on the matter)?.
* Mark: If we are stabilizing intrinstics, would like to continue having access to intrinstic with a const argument via the old API style. I.e. we should continue providing both API styles.
* Josh: Lets not dig ourselves deeper until we have more information. We can always add new ways to call a function.
* Felix: but if stdarch adds a new intrinsic that *only* offers the const generic API, then that may bias our attempt to get customer data here
* Mark: not sure if I *want* more user opinion on this, but I'm not opposed.
* Mark: if a user comes to us and says they actively dislike the const generic form, then that would change my opinion. If someone says they *like* it, that would not change my opinion
*

## Other things

* `k#foo`