Triage meeting 2021-03-30

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