---
title: Triage meeting 2021-05-11
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2021-05-11
## Attendance
* Team members: nikomatsakis, Josh, cramertj, scottmcm
* Others: simulacrum, Mara
## Meeting roles
* Action item scribe: simulacrum
* Note-taker: nikomatsakis
## Scheduled meetings
- **Tomorrow:** "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)
- Need doc from Esteban!
- **May 19:** "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93)
- Action item: Niko to ping groups =)
- **May 26:** "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
* No progress, Niko still planning to do a bit of a write-up. Probably won't happen for a week or two.
## Nominated RFCs
No nominated RFCs this time.
* https://github.com/rust-lang/rfcs/pull/2316
* not an rfc, but another FCP: https://github.com/rust-lang/rust/pull/84988 (allow safe `target_feature`)
## P-high issues on rust-lang/rust
### "`fn() -> Out` is a valid type for unsized types `Out`, and it implements `FnOnce<(), Output = Out>`" rust#82633
**Link:** https://github.com/rust-lang/rust/issues/82633
* Esteban, Felix, and Niko spent time digging into this.
* We decided that we don't like Niko's branch and would prefer Esteban's general approach, but want to dig into what kind of problems arose.
* More work is needed.
### "Closures are unsound: 'static closures with non-'static return types." rust#84366
**Link:** https://github.com/rust-lang/rust/issues/84366
* Niko to review the PR again.
### "Functions, closures, and HRTB-trait-objects can implement traits such that validity of associated types is never checked." rust#84533
**Link:** https://github.com/rust-lang/rust/issues/84533
### "HRTBs are unsound: HRTB on subtrait provides HTRB on supertrait with weaker implied bounds." rust#84591
**Link:** https://github.com/rust-lang/rust/issues/84591
### "A `Pin` unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>`" rust#85099
**Link:** https://github.com/rust-lang/rust/issues/85099
* Another wacky Pin unsoundness; Niko doesn't understand well enough to summarize yet.
* Related and similar to [#68015](https://github.com/rust-lang/rust/issues/68015).
## 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"" rust#51999
**Link:** https://github.com/rust-lang/rust/issues/51999
Unchecked action items:
* 2021-04-27: ALL to review panic in consts stabilization https://github.com/rust-lang/rust/issues/51999
* 2021-04-27: Niko to move panic in consts stabilization to its own thread https://github.com/rust-lang/rust/issues/51999
* [Stabilization report](https://github.com/rust-lang/rust/issues/51999#issuecomment-826346762)
* Nobody has looked closely into it yet
* Action item: scottmcm to read into it and propose FCP if it seems appropriate
### "Add `expr202x` macro pattern" rust#84364
**Link:** https://github.com/rust-lang/rust/pull/84364
> This makes it possible to use `inline_const` (#76001) and `let_chains`
(#53667) inside macros' `expr` patterns in a future edition by
bifurcating the `expr` nonterminal in a similar way to `pat2021` to
remove some backwards compatibility exceptions that disallow
`const`/`let` at the beginning of an `expr` match.
* [More detailed writeup](https://github.com/rust-lang/rust/pull/84364#issuecomment-823537483)
* TL;DR: The full set of expressions have diverged somewhat
* Proposal:
* Move this to an issue linked from the two tracking issues
* Desire a clear summary of grammar changes required
* what does expr match now that it did not before
* assess what impact of this change might be
* (crater run might be desired)
* Edition migration that would be required
* Is there actual ambiguity required here? Can we get an example of something that changes behavior?
* Action item:
* Felix to write the above, link issue, and remove nomination
### "Tracking issue for unsizing casts in const fns" rust#64992
**Link:** https://github.com/rust-lang/rust/issues/64992
* Ralf proposed stabilization and prepared a [stabilization report](https://github.com/rust-lang/rust/issues/64992#issuecomment-835387521)
Example:
```rust=
const fn test() {
let _x = NonNull::<[i32; 0]>::dangling() as NonNull<[i32]>;
}
```
* Already stable in const item bodies
* Somebody to fcp merge -- on the [PR #85078](https://github.com/rust-lang/rust/pull/85078)
### "Allow unused variables with todo!" rust#79850
**Link:** https://github.com/rust-lang/rust/pull/79850
* Pending action item:
* [ ] [2021-05-04]: Niko to track down expect RFC and point people at it https://github.com/rust-lang/rust/pull/79850
* No discussion this week, will remove nomination.
### "Implement new lint for detecting buggy pointer-to-int casts" rust#81789
**Link:** https://github.com/rust-lang/rust/pull/81789
* Proposal last week:
* don't claim to fix the original problem but still land this warning
* Question now:
* How valuable is this lint on its own?
* cramertj: If you are casting a pointer to a `u32`, you'r probably trying to do something. What case are we actually trying to fix?
* Niko: it would be nice to have an actual bug
* scottmcm: we're generally eliminating cases... u64, usize, isize...
* josh: I've written a lot of low level bit manipulation code in Rust which required a lot of as casts. It's not hard for me to imagine accidentally stuffing a pointer instead of what I wanted. Ironically C would give me more cross-checks via compiler warnings here, since C generally warns about casting from a pointer to a "smaller than integer" size for the current platform.
* Niko: I remember having a bug where I was casting a fat pointer to a usize and somehow getting it cast back with a junk vtable, it was one of the worst bugs I ever had to track down. I could see this catching a mistake in that vein.
* Scott: Should we consider lints being aware of the current target? Fewer false warnings in exchange for "less portability".
* Mark: that can be a real pain -- e.g., on rust ci whenever something is specific to one configuration, it's very confusing.
* Niko: +1, I'd rather we have some evidence that this is really important
* Felix: Consider a lint group?
* Niko: I would like to have `#![allow(nonportable_32_bit)]`
* Josh: could start at allow and allow opt-in
* Scott: if there was an explicit method for casting, like `to_bits` and `from_bits`, wouldn't that be a better situation?
* then we could disallow these `as` casts altogether
* josh: e.g, a `truncate` method that only took integer to small integer...?
* Mara: what about the fat pointer situation?
* Josh: maybe disallow it on fat pointers, only permit it on thin pointers
* Niko: yes you can say if you want the data pointer
* Niko: I'm in favor of introducing better alternatives to `as` and deprecating its usage
* Josh: I am doing a lot of 64-bit indexing, interconversion between usize and u64 is pretty annoying
* it'd be nice to have a method that interconverts from usize to just u64 (or u32) depending on target - size *must* match for that one
* scott: I'd rather we could just index by all the unsigned types
* Action items:
* Josh, Mara to start thread on T-libs to discuss those methods
* cc PR author, t-lang
* Summary on issue (Mark)
* we would like to have methods to point people to, and a simpler lint
### "add back support for inner attributes on non-block expressions?" rust#84879
**Link:** https://github.com/rust-lang/rust/issues/84879
* Turns out that some internal tool (rustfmt) relies on this, came up on internals
* Related: https://github.com/rust-lang/rust/pull/84414
```rust=
struct S {
#![doc = ""]
}
enum E {
#![doc = ""]
}
union U {
#![doc = ""]
}
```
* Niko: Seems similar-ish to match patterns
* Inner attributes: how useful?
* Top-level on a module
* Some tricks with attributes in macros
* Tagging bodies of match arms or if expressions
* `match foo { 33 => { #![likely] ... } }` -- still allowed after this PR
* Resolving ambiguity `(`
* `#[likely] if foo { ...} else { }` // how do you even tag the else
* `(#![foo] 3 + 2)` -- disallowed by ths PR
* What about `if some_intrinsic::likely(foo) { ... } else { ... }`
* there are a bunch of arguments here -- see https://github.com/rust-lang/rust/issues/26179
* Does anyone have an active argument in favor of keeping inner attributes in these positions?
* Mark: It did break 4 crates https://github.com/rust-lang/rust/pull/83312#issuecomment-809599116
* Niko: if we add support in structs, I'd expect it to work in matches, they look very similar
* Origin of the performance concern?
* Procedural macros have to carry some baggage? (at least we think that's related)
* ["Custom inner attributes in expressions are banned,"](https://github.com/rust-lang/rust/pull/83312#issuecomment-825113447)
* Josh: there was a procedural failure in that we failed to register a concern
* so we have to choose between "make a decision really fast" and "discuss and decide at our leisure"
* felix: might that not mean more crates appear?
* Should we lint?
* Josh: what about a warning period?
* [policy](https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html#is-it-ever-acceptable-to-go-directly-to-issuing-errors)
* Summary:
* Niko: Ask about implications of reverting for match
### "Allow struct and enum to contain inner attrs" rust#84414
**Link:** https://github.com/rust-lang/rust/pull/84414
- Related to the above
### "Stabilize "RangeFrom" patterns" rust#83918
**Link:** https://github.com/rust-lang/rust/pull/83918
From previous meeting:
* We requested this
* [Stabilization writeup](https://github.com/rust-lang/rust/pull/83918#issue-609576583)
* scottmcm proposed fcp merge
* Action item for folks: check your boxes
### "Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039
**Link:** https://github.com/rust-lang/rust/pull/84039
* Josh FCP'd, so check your boxes
### "Deny float matches" rust#84045
**Link:** https://github.com/rust-lang/rust/pull/84045
Last meeting:
> Niko: volunteers to write up a proposal and run it by const generics working group to double check his reasoning
### "stabilize member constraints" rust#84701
**Link:** https://github.com/rust-lang/rust/pull/84701
* FCP
Sign in with Wallet
Connect another wallet