---
# System prepended metadata

title: Triage meeting 2021-03-30
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-03-30

## Attendance

* Team members: Scott, Taylor, Josh, Felix
* Others: simulacrum

## Meeting roles

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

## Scheduled meetings
-  "How to dismantle an `&Atomic` bomb." [lang-team#82](https://github.com/rust-lang/lang-team/issues/82)
    -  a blog post is available on felix's blog, if you want to read it
    -  but felix is working on a condensed write-up

Completed:
-  "2021 idiom lint overview" [lang-team#83](https://github.com/rust-lang/lang-team/issues/83)
-  "RFC backlog bonanza recap" [lang-team#84](https://github.com/rust-lang/lang-team/issues/84)
-  "lang team reorg: shepherds 4.0, triage update" [lang-team#85](https://github.com/rust-lang/lang-team/issues/85)

## 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
- Niko sent messages encouraging a summary of the zulip thread
    - Goal is to get a design note summary
    - Niko notes that we have pending design notes PRs

## Nominated RFCs
No nominated RFCs this time.

## 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
- Lang-team decision needed: confirm that we want to restrict either the existence of `fn() -> Out` where `Out: ?Sized`, or that we want such types to not impl `FnOnce`.
- rfcbot poll: https://github.com/rust-lang/rust/issues/82633#issuecomment-810416081
- esteban had volunteered to do work in this regard, left a comment to ping him

## 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 2457, "Allow non-ASCII identifiers"" rust#55467

**Link:** https://github.com/rust-lang/rust/issues/55467
- FCP merge proposed, un-nominated
- pnkfelix, scottmcm have not checked
- [manish comment](https://github.com/rust-lang/rust/issues/55467#issuecomment-802302837)
- [stabilization report linked in this comment](https://github.com/rust-lang/rust/issues/55467#issuecomment-803202449)

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

**Link:** https://github.com/rust-lang/rust/pull/81789
- Prior discussion:
    - Consensus that we do not want to flag casts to `u64` (too many false warnings)
- Question for today:
    - Do we want the new lint to warn by default?
        - Warn when you cast `*const ()` to `u8`, ... `u32`, `u128` -- anything apart from `usize` and `u64`
- Q: Motivation for warning when casting to `u128`?
    - Conclusion: Nobody noticed.
- Q: Is this one lint? Does it treat function items and function pointers differently from data pointers?
    - Scott observes that casting a function item (e.g., `u64::max_value as u64`) gives you the `u64` of the function pointer, and not the max-vaue of `u32`.
    - The actual bug that is being fixed is this specific case -- casting a function item to an integer.
    - Could special case functions whose return type is `u64` (*pnkfelix: or any uN/fN kind*) and flag it; could imagine heuristics for "functions you are less likely to want to convert to a function pointer".
    - Niko observes that `usize::max_value as usize` would also be error-prone.
- Could we have some alternative, non-as based way to do this? Perhaps a function, and then we can lint more aggressively on `as`?
    - Scott observes that if you want a pointer from an array you do `as_ptr`, not cast it.
- Josh proposes:
    - We probably want *this* lint
    - But it sounds like it does not address the original issue and therefore we probably want a second lint as well
- Scott: can we make the PR not declare that it 'fixes' the issue?
    - Action item: Scott to change the OP and clarify how this PR fails to address the issue (even though it is a good change)
- Scott: should this be target dependent? If I were on a 32-bit platform, this would be noisy.
    - Josh: last time we discussed saying that people on 32-bit platforms can `#![allow]` the lint.
    - But this does kind of go against our "avoid false warnings" policy, at least on those platforms.
- Question is basically how likely is this to be a bug?
    - Feels like it's kind "noisy and heuristicy", since the code is sometimes correct
- Confusions
    - I meant to call a function but I got a function pointer
    - I meant to reference a similarly named constant
    - I meant to dereference a pointer (and then convert the resulting data)
    - I accidentally wrote non-portable code by casting to u32
- Use cases people want to do
    - taking the low bits of a pointer (will never be used as a pointer again)
    - getting the pointer as an integer (may turn back into a pointer)
    - using u64 as a "big enough for a pointer on any platform" with a fixed size (happens e.g. in the linux kernel)
    - I'm on Win32 and writing `as DWORD`
- Precedent around portability?
    - example: we don't let you index with u32 even though on a 32-bit platform it'd be fine
        - feels different because we don't permit it with u64 too
        - Mark question: is this a lint?
- Procedural question:
    - In previous meeting, we had a consensus, but of course now we seem to be revisiting it.
    - Why did folks change their minds?
        - cramertj: I was focused before just on the question of "pointer to u64" being ok, not the overall context of the lint in general
            - I was not aware of the full context, that it didn't address the spirit of the problem described in the original issue
            - Clippy's big list of lints, with what it's for and what you should use instead https://rust-lang.github.io/rust-clippy/master/index.html
        - Niko: I was thinking that it might be useful in the future to create a kind of "lint proposal" that indicates "what is the user confusion we are trying to address" and "what should user do instead"
- Proposal:
    - Discuss more on the issue

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

**Link:** https://github.com/rust-lang/rust/pull/82918
- FCP merge proposed, un-nominated
- not checked: pnkfelix, scottmcm, cramertj
- scott: this is just "use `_: Foo` and not just `Foo`, right?"
    - Answer: yes.

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

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

* Still awaiting input and opinions from users; left some comments.

### "Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021" rust#83213

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

* Outcome of our "lint review" process
    * An error to write `Trait` and not `dyn ` (in Rust 2021)
    * An error to write `...` and not `..=` (in Rust 2021)
* One potential complication:
    * If macro-rules from 2018 crates generates a bare trait reference, that should not be an error
* Proposal fcp to merge
    * with caveat that we use the spans of `Trait` and `...`
    * with a concern that we should tie the edition to the specific span
* Note:
    * we should specify what span do we derive the error from when we accept RFCs etc

### "Stabilize extended_key_value_attributes" rust#83366

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

* There is a stabilization report (huzzah)
* Major use case: ability to do `include_str!` on doc; this is an alternative to the `doc::include` mechanism
* cramertj: as a user, this feels like eager expansion, was there an RFC?
    * came from [PR #78837](https://github.com/rust-lang/rust/pull/78837)
    * [writeup is this blog post on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
* Josh: difference between this and eager expansion is that it is primarily targeting "inert attributes" like doc
    * cramertj: but as a user of procedural macros, the difference is not obvious; feels surprising that I can pass it in others
* petrochenkov had [two questions](https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738) to be considered

### "`#[repr(align(8))]` is not accepted for arrays" rust#83595

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


## Extra item

### k#keywords for 

* RFC https://github.com/rust-lang/rfcs/pull/3098 would need to be accepted soon
* Question
    * In previous editions (2015, 2018), do we want some *alternative* syntax (e.g., `r#$foo`).
        * Josh: Would like to have this defined in the RFC (not just as a "we could")
* Possible extension
    * Can reserve `[a-zA-Z_]#keyword` in general
    * Can reserve `[a-zA-Z_]"string"` in general

Extra change:
 - `b"asdf"` being one token and `a"asdf"` being two is weird, so we can just make the lattter a tokenization error, freeing up space for future extension.
