---
title: Triage meeting 2024-10-23
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2024-10-23
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202024-10-23
url: https://hackmd.io/OzcWNVayR0KvnvMBq2GYRw
---
# T-lang meeting agenda
- Meeting date: 2024-10-23
## Attendance
- People: TC, nikomatsakis, pnkfelix, tmandry, Yosh, Xiang
## Meeting roles
- Minutes, driver: TC
## Scheduled meetings
- 2024-10-23: "Design meeting: Trait modifiers / RFC 3710" [#294](https://github.com/rust-lang/lang-team/issues/294)
- https://hackmd.io/@rust-lang-team/ryxu3YLx1e is the document
- 2024-10-30: "Rust spec update" [#295](https://github.com/rust-lang/lang-team/issues/295)
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
## Announcements or custom items
(Meeting attendees, feel free to add items here!)
### Guest attendee items
TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.
### Moving right along
TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.
### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET
TC: Remember that we have a design/planning meeting that starts half an hour after this call ends.
### Next meeting with RfL
We're next meeting with RfL on 2024-10-23 to review the status of RfL project goals.
https://github.com/rust-lang/rfcs/pull/3614
## Rust 2024 review
Project board: https://github.com/orgs/rust-lang/projects/43/views/5
None.
### Meta
TC: We have tracking issues for the Rust 2024 aspects of every item queued for the edition:
https://github.com/rust-lang/rust/issues?q=label%3AA-edition-2024+label%3AC-tracking-issue
For each item, we've identified an *owner*.
Our motivating priorities are:
- Make this edition a success.
- Do so without requiring heroics from anyone.
- ...or stressing anyone or everyone out.
The current timeline is:
| Date | Version | Edition stage |
|------------|---------------|--------------------------------|
| 2024-10-11 | Branch v1.83 | Go / no go on all items |
| 2024-10-17 | Release v1.82 | Rust 2024 nightly beta |
| 2024-11-22 | Branch v1.84 | Prepare to stabilize... |
| 2024-11-28 | Release v1.83 | Stabilize Rust 2024 on master |
| 2025-01-03 | Branch v1.85 | Cut Rust 2024 to beta |
| 2025-01-09 | Release v1.84 | Announce Rust 2024 is pending! |
| 2025-02-20 | Release v1.85 | Release Rust 2024 |
All lang priority items are ready for Rust 2024. The remaining not-ready lang items are:
### "Tracking Issue for RFC 3606: Drop temporaries in tail expressions before local variables" rust#123739
**Link:** https://github.com/rust-lang/rust/issues/123739
### "Tracking Issue for Rust 2024: Deny references to static mut" rust#123758
**Link:** https://github.com/rust-lang/rust/issues/123758
### "Tracking Issue for Rust 2024: Rescope temporary lifetimes with respect to `else`" rust#124085
**Link:** https://github.com/rust-lang/rust/issues/124085
### "Tracking issue for Rust 2024: Match ergonomics rules 1C/2C" rust#131414
**Link:** https://github.com/rust-lang/rust/issues/131414
## Nominated RFCs, PRs, and issues
### "Tracking Issue for `ptr::fn_addr_eq`" rust#129322
**Link:** https://github.com/rust-lang/rust/issues/129322
TC: Over in...
https://github.com/rust-lang/rust/pull/118833
...we recently started an FCP to lint against function pointer comparisons and to push people toward `ptr::fn_addr_eq`. Now to support that, libs-api proposes a dual-FCP with us to stabilize `fn_addr_eq`.
TC: Clearly we want this. Let's check our boxes.
### "Fix ICE when passing DefId-creating args to legacy_const_generics." rust#130443
**Link:** https://github.com/rust-lang/rust/pull/130443
TC: This proposes to make an error out of:
```rust
std::arch::x86_64::_mm_blend_ps(loop {}, loop {}, foo::<3>());
```
...and similar cases that lean on `legacy_const_generic`.
This is not believed to break anything in practice and is being done for implementation reasons.
TC: This is marked as an easy decision for us. Do we agree?
In terms of what `legacy_const_generic` is, consider the signature of `_mm_blend_ps`:
```rust
pub unsafe fn _mm_blend_ps(a: __m128, b: __m128, const IMM4: i32) -> __m128
```
Note the `const IMM4` argument.
NM: This is probably a good idea, but it does point to a need for better documentation about exactly what we accept here.
tmandry: How would people write the example above?
all:
```rust
std::arch::x86_64::_mm_blend_ps::<foo::<3>()>(loop {}, loop {});
```
The rustdocs show the sugary one, but the source is actually in normal const generic form.
tmandry: I'm losing confidence this is an easy call.
Josh: We should note this in the release notes, as it is a breaking change. We could precommit to rolling it back if people encounter actual breakage.
NM: I'm not sure I'd want to precommit to that; I'd like to see their code.
tmandry: It seems we might have some clarifying questions here.
NM: I'd like to know not what's being rejected, but an exhaustive list of what we're accepting. I might be willing to do more aggressive breakage to have a clear story about what people can write. I'll write a comment to ask.
### "Trait method impl restrictions" rfcs#3678
**Link:** https://github.com/rust-lang/rfcs/pull/3678
TC: This RFC just went into FCP with some changes. We switched out `final` for `#[inherent]` and added an open question about syntax.
TC: This is just a heads-up to people who had already checked boxes about that.
One motivation for "inherent" is:
```rust
trait Tr {}
impl dyn Tr {
...
}
```
->
```rust
trait Tr {}
impl (impl Tr) {
...
}
```
->
```rust
trait Tr {}
impl Tr {
...
}
```
NM: It may be worth revisiting the mental model around specialization because from that point of view final made sense to me. The model there was that you have a trait which only defines method signatures. Then you have impls which provide definitions for some subset of those methods. A given method for a given type can be abstract, default, or final. If any of the methods are abstract, the trait is not implemented. If any of the methods are default, they can be specialized by other impls. We can call an impl that doesn't provide at least a default method for everything a "partial impl". In this way, a trait with default methods is a combo of a trait + a partial impl. Also, the default in traits is either abstract or default, and the default in an impl is final. So:
```rust
trait Something {
fn foo(); // => abstract
fn bar() { } // => default
final fn baz() { }
}
// is equivalent to
trait Something {
fn foo();
fn bar();
}
// with an impl like this (not the syntax we used in the RFC, as I recall, but maybe a better one)...
impl<T: ?Sized> Something for T {
abstract fn foo();
default fn bar() { }
fn baz() { } // => final, can't be changed by specializing impls
}
```
Anyway, that's how I think of it, but I'll ponder over this "inherent" thing. I'm fine with whatever to unblock but the naming confused me, as I think of inherent being tied to members that are acecssible without having a trait in scope (i.e., inherent to a type, they can be used just by virtue of knowing the type of the owner).
### "Supertrait item shadowing v2" rfcs#3624
**Link:** https://github.com/rust-lang/rfcs/pull/3624
TC: This RFC is in FCP. One of the main motivations for this RFC is so that libs-api can stabilize methods whose names match those used by `itertools`. Since the FCP started, one of the maintainers of `itertools` chimed in to say:
> tmandry said:
> > We'll be creating a slightly bad experience for users of itertools with the lint, and that will only be resolved by the crate releasing a new semver-incompatible version or a new trait (or perhaps doing rustc version hacks, if the signatures are compatible).
>
> This is going to create a slightly bad experience for the maintainers of itertools, too. We _will_ get issues filed by users who would like us to remove now-shadowing methods for their toolchain because of the lint. (If we're very unlucky, those users will have also discovered that the rationale for the lint is to avoid supply chain attacks.) We won't be able to readily remove these methods, because that conflicts with our longstanding policy of maintaining a conservative MSRV. The only way we'll be able to reconcile these interests is by using `build.rs`-rustc-version-detection hacks, something we've intentionally avoided _because `build.rs` is a vector for supply chain attacks_.
>
> Please consider making this lint allow-by-default.
I nominated so we could consider that feedback. We could of course handle the setting of the lint level during stabilization, but it seems worth discussing this feedback while it's fresh.
TC: What do we think?
JT (rather poorly summarized): There are features under consideration that would improve the experience (e.g., `foo.Trait::method()` or cfg-accessible) but blocking on those doesn't make sense. Also, the motivation for the lint is user-confusion, not supply-chain.
TC: I'm skeptical of this lint. If someone writes this...
```rust
fn f(x: impl SubTrait) {
x.foo();
}
```
...it seems clear the user means to call the subtrait.
Also, we may be over-focusing on `intersperse`. If the subtrait method has a different behavior, then the user will continue to want to call the subtrait one.
There's a language consistency element here with inherent methods. If we want to lint against the above, we should be linting against trait methods shadowing inherent ones, but we don't do that.
FK: the people most qualified to judge equivalence is probably the people defining the trait. Can we delegate the allow/warn-by-default to the third-party crate via some attribute mechanism?
JT: I expect you could add that mechanism, I doubt it's excessively difficult to implement, but I suspect that the traits in question won't be able to use it because of MSRV concerns. If we had cfg-version, they could do that, but then they could use it to just not declare the method in the first place.
NM: I don't think they can just drop the method altogether because of calls like `IterTools::method`?
JT: Ideally this would work, because `Subtrait::supermethod` should work, but it doesn't: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=be97e0ea62e7110d95213f4736ca2e8b
NM: Shipping this `allow-by-default` makes sense to me, I would like to revisit the question once we have a better story for IterTools-crate authors (i.e., a way for them to conditionally deprecate based on availability).
JT: I prefer warn-by-default but I would not block. This feature is important.
tmandry: Maybe we should lint against inherent methods shadowing trait methods. But I agree we should ship this with `allow-by-default` until we have a better story here.
... some discussion about whether it can be confusing and possible mechanisms for managing MSRV here ...
NM: I think the story ought to be that, if you subtrait a std-trait like `Iterator` and a method is added to `Iterator` that "reverse-shadows" your method, you ought to deprecate your method. kind of annoying but them's the breaks. It's in the best interest of your users because it will be confusing, e.g., consider...
```rust
fn f(x: impl PartiallyOrderedIterator) {
x.map(...) // but actually `map` is overridden
}
```
...if you are not familiar with the details of that trait, but you are familiar with iterators, you will be confused.
TC: Net-net then, we need a better story, and we'll make this allow-by-default until then. I'll either leave a comment or update the RFC directly, and we'll let this go into FCP.
### "Split elided_lifetime_in_paths into tied and untied" rust#120808
**Link:** https://github.com/rust-lang/rust/pull/120808
TC: The context here is:
> Types that contain a reference can be confusing when lifetime elision occurs:
>
```rust
// Confusing
fn foo(_: &u8) -> Bar { todo!() }
// Less confusing
fn foo(_: &u8) -> Bar<'_> { todo!() }
```
>
> However, the previous lint did not distinguish when these types were not "tying" lifetimes across the function inputs / outputs:
>
```rust
// Maybe a little confusing
fn foo(_: Bar) {}
// More explicit but noisier with less obvious value
fn foo(_: Bar<'_>) {}
```
>
> We now report different lints for each case, hopefully paving the way to marking the first case (when lifetimes are tied together) as warn-by-default (#91639).
>
> Additionally, when multiple errors occur in the same function during the tied case, they are coalesced into one error. There is also some help text pointing out where the lifetime source is.
TC: In that light, jleyouxu nominates for us:
> ...what should the split up `elided_lifetimes_in_paths` lints be called?
>
> > The lints are called `elided_lifetimes_in_paths_tied` and `elided_lifetimes_in_paths_untied`, under a lint group of `elided_lifetimes_in_paths`. The usage of "tied" and "untied" introduces new terminology for a concept that is not new.
> > We had [a discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Terminology.20for.20input.20lifetimes.20relating.20to.20output.20lifetimes) about other phrasing, but no super strong alternative arose. "tied" is not the most beautiful choice, but it's serviceable.
> > Beyond "tied", a good argument has been made that the current lint name is factually incorrect (tl;dr: both `Foo` and `Foo<'_>` perform lifetime elision; `Foo` has a hidden lifetime while `Foo<'_>` has explicit syntax). A follow up PR could rename these lints to be more accurate.
TC: What do we think?
### "Stabilize `#[diagnostic::do_not_recommend]`" rust#132056
**Link:** https://github.com/rust-lang/rust/pull/132056
TC: welznich proposes for us to stabilize `#[diagnostic::do_not_recommend]`.
We accepted an earlier version of this in RFC 2397, then later moved this to the `diagnostic` namespace.
TC: What do we think?
### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641
**Link:** https://github.com/rust-lang/rfcs/pull/3641
TC: This RFC would allow writing:
```rust
#[no_mangle]
#[export_ordinal(1)]
pub extern "C" fn hello() {
println!("Hello, World!");
}
```
TC: There's a long-outstanding FCP. Josh nominates this for us to collect checkboxes. What do we think?
### "Tracking Issue for enum access in offset_of" rust#120141
**Link:** https://github.com/rust-lang/rust/issues/120141
TC: There's a proposed FCP merge for us:
https://github.com/rust-lang/rust/issues/120141#issuecomment-2161507356
TC: What do we think?
### "Remove unstable cfg `target(...)` compact feature" rust#130780
**Link:** https://github.com/rust-lang/rust/pull/130780
TC: Urgau suggests that we remove the `cfg_target_compact` unstable feature. Its tracking issue is:
https://github.com/rust-lang/rust/issues/96901
TC: What do we think?
### "Strengthen the follow-set rule for macros" rust#131025
**Link:** https://github.com/rust-lang/rust/issues/131025
TC: Over in:
- https://github.com/rust-lang/rust/pull/130635
@compiler-errors describes this general problem:
> The breakage specifically represents an inherent limitation to the "macro follow-set" formulation which is _supposed_ to make us more resilient against breakages due to extensions to the grammar like this.
>
> Given two macro matcher arms:
>
> * `($ty:ty) => ...`
> * `(($tt:tt)*) => ...`
>
> And given tokens like:
>
> * `&` `pin` `mut` [...more tokens may follow...]
>
> On nightly today, `&pin` gets parsed as a type. However, we run out of matchers but still have tokens left (the `mut` token is next), so we fall through to the next arm. Since it's written like `($tt:tt)*`, everything is allowed, and we match the second arm successfully...
>
> I think that's weird, because if this second arm were written like `$ty:ty mut`, that would be illegal, since `mut` is not in the follow-set of the `:ty` matcher. Thus, we can use `:tt` matchers to observe whether the compiler _actually_ parses things not in our grammar that should otherwise be protected against, which seems pretty gross.
And @Noratrieb proposes a general solution:
> I believe a solution to this would be the following new logic:
>
> * after the end of a macro matcher arm has been reached
> * and there are still input tokens remaining
> * and if the last part of the matcher is a metavar
> * ensure that the first remaining token is in the follow set of this metavar
> * if it is, move on to the next arm
> * if it is not, **emit an error**
>
> What this semantically does is strengthen the "commit to fully matching metavars or error" behavior such that it extends past the end. I don't know how many macros rely on this, but it seems like emitting an FCW (instead of error) on such macro invocations would find all these cases and ensure that the follow-set logic is actually robust past the end. But imo this shouldn't block this PR (which should probably just ship as-is) and can be done separately.
About this, NM noted:
> I don't think this proposal is sufficient but I am interested in pursuing a real fix to this for a future edition.
>
> Example:
>
```rust
macro_rules! test {
(if $x:ty { }) => {};
(if $x:expr { }) => {};
}
```
>
> This basically says to pick one arm if something is a type, another if it's an expression. Extending the type grammar to cover new cases could change which arm you go down to.
>
> I *think* the most general fix is to say: when you would start parsing a fragment, first skip ahead to find the extent of it (i.e., until you see an entry from the follow-set). Then parse it as the fragment. If the parsing fails or there are unconsumed tokens, report a hard error.
>
> I suspect it would break a lot in practice and we would need an opt-in.
TC: What do we think?
### "Decide on name for `Freeze`" rust#131401
**Link:** https://github.com/rust-lang/rust/issues/131401
TC: We still need to pick a name for `Freeze` (which may still be `Freeze`) so that we can proceed with:
- https://github.com/rust-lang/rfcs/pull/3633
Having heard no options particularly more appealing options than `Freeze`, I propose we go with that as the author of that RFC has suggested.
TC: What do we think?
### "Stabilize `count`, `ignore`, `index`, and `len` (`macro_metavar_expr`)" rust#122808
**Link:** https://github.com/rust-lang/rust/pull/122808
TC: c410-f3r proposes the following for stabilization:
> # Stabilization proposal
>
> This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically, the stabilization of `count`, `ignore`, `index` and `length`.
>
> ## What is stabilized
>
> ### Count
> The number of times a meta variable repeats in total.
>
```rust
macro_rules! count_idents {
( $( $i:ident ),* ) => {
${count($i)}
};
}
fn main() {
assert_eq!(count_idents!(a, b, c), 3);
}
```
>
> ### Ignore
> Binds a meta variable for repetition, but expands to nothing.
>
```rust
macro_rules! count {
( $( $i:stmt ),* ) => {{
0 $( + 1 ${ignore($i)} )*
}};
}
fn main() {
assert_eq!(count!(if true {} else {}, let _: () = (), || false), 3);
}
```
>
> ### Index
> The current index of the inner-most repetition.
>
```rust
trait Foo {
fn bar(&self) -> usize;
}
macro_rules! impl_tuple {
( $( $name:ident ),* ) => {
impl<$( $name, )*> Foo for ($( $name, )*)
where
$( $name: AsRef<[u8]>, )*
{
fn bar(&self) -> usize {
let mut sum: usize = 0;
$({
const $name: () = ();
sum = sum.wrapping_add(self.${index()}.as_ref().len());
})*
sum
}
}
};
}
impl_tuple!(A, B, C, D);
fn main() {
}
```
>
> ### Length
>
> The current index starting from the inner-most repetition.
>
```rust
macro_rules! array_3d {
( $( $( $number:literal ),* );* ) => {
[
$(
[
$( $number + ${length()}, )*
],
)*
]
};
}
fn main() {
assert_eq!(array_3d!(0, 1; 2, 3; 4, 5), [[2, 3], [4, 5], [6, 7]]);
}
```
>
> ## Motivation
>
> Meta variable expressions not only facilitate the use of macros but also allow things that can't be done today like in the `$index` example.
>
> An initial effort to stabilize this feature was made in #111908 but ultimately reverted because of possible obstacles related to syntax and expansion.
>
> Nevertheless, [#83527 (comment)](https://github.com/rust-lang/rust/issues/83527#issuecomment-1744822345) tried to address some questions and fortunately the lang team accept #117050 the unblocking suggestions.
>
> Here we are today after ~4 months so everything should be mature enough for wider use.
>
> ## What isn't stabilized
> `$$` is not being stabilized due to unresolved concerns.
TC: I asked WG-macros for feedback on this here:
https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/Partial.20macro_metavar_expr.20stabilization
TC: Josh proposed FCP merge on this stabilization.
### "Effective breakage to `jiff` due to `ambiguous_negative_literals`" rust#128287
**Link:** https://github.com/rust-lang/rust/issues/128287
TC: We have an allow-by-default lint against `ambiguous_negative_literals` like:
```rust
assert_eq!(-1.abs(), -1);
```
It's allow-by-default because we found use cases such as `jiff` (by BurntSushi) that have, in their API, operations whose result is invariant to the order of the negation and that rely on this syntax for the intended ergonomics.
Urgau has a proposal for us. He'd like to lint by default, and have an...
```rust
#[diagnostic::irrelevant_negative_literal_precedence]
```
...attribute (of some name), using the diagnostic namespace, that could be applied to function definitions and that would suppress this lint on their callers. Urgau would prefer this be opt-in rather than opt-out so as to bring awareness to this, even though many functions don't affect the sign bit and so will have this invariance.
I've asked BurntSushi for his views on this proposal with respect to `jiff`, to confirm this would address his use case.
TC: What do we think?
### "Define raw pointer transmute behavior" reference#1661
**Link:** https://github.com/rust-lang/reference/pull/1661
TC: To satisfy a use-case in the `zerocopy` library, jostif proposes the following should be true:
> For any `*const T` / `*mut T` to `*const U` / `*mut U` cast which is well-defined as described in this section, `core::mem::transmute<*const T, *const U>` / `core::mem::transmute<*mut T, *mut U>` has the same behavior as the corresponding cast.
RalfJ has commented that exact thing can't quite be true, but similar things probably could be.
TC: What do we think?
### "Simplify lightweight clones, including into closures and async blocks" rfcs#3680
**Link:** https://github.com/rust-lang/rfcs/pull/3680
TC: Josh nominates a new RFC for us. What do we think?
### "[RFC] Default field values" rfcs#3681
**Link:** https://github.com/rust-lang/rfcs/pull/3681
TC: This RFC adds a way to set field defaults, e.g.:
```rust
struct Point {
x: u8 = 0,
y: u8 = 0,
}
let p = Point { .. };
```
But, unfortunately, the interaction with `Default` here is a bit weird. If we write:
```rust
struct Point {
x: u8,
y: u8,
// We just want to override the default `None` on this field,
// but we can leave the others alone because `Default::default`
// for those is fine, right?
z: Option<u8> = Some(0),
}
let p = Point { .. }; //~ ERROR
let p = Point::default(); //~ OK!
```
In general, under this RFC, `Point { .. }` and `Point::default()` can each work when the other can fail and can have arbitrarily different behaviors. So it's in that context that I [nominate](https://github.com/rust-lang/rfcs/pull/3681#issuecomment-2370130867), suggestion a nightly experiment, and propose a design meeting.
https://github.com/rust-lang/lang-team/issues/291
TC: What do we think?
### "Declarative `macro_rules!` attribute macros" rfcs#3697
**Link:** https://github.com/rust-lang/rfcs/pull/3697
TC: Josh proposes an RFC for us:
> Many crates provide attribute macros. Today, this requires defining proc macros, in a separate crate, typically with several additional dependencies adding substantial compilation time, and typically guarded by a feature that users need to remember to enable.
>
> However, many common cases of attribute macros don't require any more power than an ordinary `macro_rules!` macro. Supporting these common cases would allow many crates to avoid defining proc macros, reduce dependencies and compilation time, and provide these macros unconditionally without requiring the user to enable a feature.
E.g.:
```rust
macro_rules! main {
attr() ($func:item) => { make_async_main!($func) };
attr(threads = $threads:literal) ($func:item) => { make_async_main!($threads, $func) };
}
#[main]
async fn main() { ... }
#[main(threads = 42)]
async fn main() { ... }
```
TC: What do we think?
### "Declarative `macro_rules!` derive macros" rfcs#3698
**Link:** https://github.com/rust-lang/rfcs/pull/3698
TC: Josh proposes an RFC for us:
> Many crates support deriving their traits with `derive(Trait)`. Today, this requires defining proc macros, in a separate crate, typically with several additional dependencies adding substantial compilation time, and typically guarded by a feature that users need to remember to enable.
>
> However, many common cases of derives don't require any more power than an ordinary `macro_rules!` macro. Supporting these common cases would allow many crates to avoid defining proc macros, reduce dependencies and compilation time, and provide these macros unconditionally without requiring the user to enable a feature.
E.g.:
```rust
trait Answer { fn answer(&self) -> u32; }
#[macro_derive]
macro_rules! Answer {
// Simplified for this example
(struct $n:ident $_:tt) => {
impl Answer for $n {
fn answer(&self) -> u32 { 42 }
}
};
}
#[derive(Answer)]
struct Struct;
fn main() {
let s = Struct;
assert_eq!(42, s.answer());
}
```
TC: What do we think?
### "Macro fragment fields" rfcs#3714
**Link:** https://github.com/rust-lang/rfcs/pull/3714
TC: This RFC proposes to allow:
```rust
macro_rules! get_name {
($t:adt) => { println!("{}", stringify!(${t.name})); }
}
fn main() {
let n1 = get_name!(struct S { field: u32 });
let n2 = get_name!(enum E { V1, V2 = 42, V3(u8) });
let n3 = get_name!(union U { u: u32, f: f32 });
println!("{n3}{n1}{n2}"); // prints "USE"
}
```
That is, it lets MBE authors use the Rust parser to pull out certain elements.
TC: What do we think?
### "Elided lifetime changes in `rust_2018_idioms` lint is very noisy and results in dramatically degraded APIs for Bevy" rust#131725
**Link:** https://github.com/rust-lang/rust/issues/131725
TC: Long ago, we set a direction of wanting to move away from eliding lifetimes in paths, e.g.:
```rust
#![deny(elided_lifetimes_in_paths)]
struct S<'a>(&'a ());
fn f(x: &()) -> S {
// ~
//~^ ERROR expected lifetime parameter
S(x)
}
```
However, that lint is currently `allow-by-default`. It was part of the `rust_2018_idioms` lint group (which is also `allow-by-default`).
We talked about changing this in Rust 2024, but it seems we didn't get around to it.
One of the maintainers of Bevy has now written in to ask us to never change this.
I'd probably highlight:
- The representativeness of the example being challenged.
- https://github.com/rust-lang/rust/issues/131725#issuecomment-2413272045
- Details about the lint and what would actually be flagged.
- https://github.com/rust-lang/rust/issues/91639#issuecomment-2413823502
TC: What do we think?
### "Add support for `use Trait::func`" rfcs#3591
**Link:** https://github.com/rust-lang/rfcs/pull/3591
This RFC would add support for:
```rust
use Default::default;
struct S {
a: HashMap<i32, i32>,
}
impl S {
fn new() -> S {
S {
a: default()
}
}
}
```
Josh has proposed FCP merge and has nominated. There are outstanding concerns about the handling of turbofish and associated constants.
TC: What do we think?
### "Tracking issue for the `start` feature" rust#29633
**Link:** https://github.com/rust-lang/rust/issues/29633
TC: Nils proposes to us that we delete the unstable `#[start]` attribute:
> I think this issue should be closed and `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
>
> I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
>
> * `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
> * `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things _anyways_
>
> `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on Windows, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving _any_ stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
>
> Note that this feature has **not** been RFCed in the first place.
TC: What do we think?
### "Coercing &mut to *const should not create a shared reference" rust#56604
**Link:** https://github.com/rust-lang/rust/issues/56604
TC: It's currently UB to write:
```
fn main() {
let x = &mut 0;
let y: *const i32 = x;
unsafe { *(y as *mut i32) = 1; }
assert_eq!(*x, 1);
}
```
This is due to the fact that we implicitly first create a shared reference when coercing a `&mut` to a `*const`. See:
TC: What do we think about this?
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
**Link:** https://github.com/rust-lang/rust/pull/107378
TC: We unnominated this back in October 2023 as more analysis seemed to be needed. Since then, nikomatsakis and tmandry have posted substantive analysis that it seems we should discuss.
### "#[cold] on match arms" rust#120193
**Link:** https://github.com/rust-lang/rust/pull/120193
TC: Apparently our unstable `likely` and `unlikely` intrinsics don't work. There's a proposal to do some work on fixing that and stabilizing a solution here. The nominated question is whether we want to charter this as an experiment.
### "Emit a warning if a `match` is too complex" rust#122685
**Link:** https://github.com/rust-lang/rust/pull/122685
TC: Nadri nominates this for us and describes the situation:
> Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.
>
> We _could_ make the limit configurable or the warning `allow`able. I argue that's not necessary because [crater](https://github.com/rust-lang/rust/pull/121979#issuecomment-2003089646) showed zero regressions with the current limit, and it's be pretty easy in general to split up a `match` into smaller `match`es to avoid blowup.
>
> We're still figuring out the exact limit, but does the team approve in principle?
(As an aside, awhile back someone [showed](https://niedzejkob.p4.team/rust-np/) how to [lower](https://github.com/NieDzejkob/rustc-sat) SAT to exhaustiveness checking with `match`. Probably that would hit this limit.)
TC: What do we think?
### "Tracking Issue for unicode and escape codes in literals" rust#116907
**Link:** https://github.com/rust-lang/rust/issues/116907
TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:
> I have a partial implementation of this RFC working locally (EDIT: now at #120286). The RFC proposes five changes to literal syntax. I think three of them are good, and two of them aren't necessary.
TC: What do we think?
### "Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint" lang-team#255
**Link:** https://github.com/rust-lang/lang-team/issues/255
TC: Trevor Gross describes the situation:
> For a while, Rust's 128-bit integer types have been incompatible with those from C. The original issue is here [rust-lang/rust#54341](https://github.com/rust-lang/rust/issues/54341), with some more concise background information at the MCP here [rust-lang/compiler-team#683](https://github.com/rust-lang/compiler-team/issues/683)
>
> The current Beta of 1.77 will have [rust-lang/rust#116672](https://github.com/rust-lang/rust/pull/116672), which manually sets the alignment of `i128` to make it ABI-compliant with any version of LLVM (`clang` does something similar now). 1.78 will have LLVM18 as the vendored version which fixes the source of this error.
>
> Proposal: now that we are ABI-compliant, do not raise `improper_ctypes` on our 128-bit integers. I did some testing with abi-cafe and a more isolated https://github.com/tgross35/quick-abi-check during the time https://reviews.llvm.org/D86310 was being worked on, and verified everything lines up. (It would be great to have some fork of abi-cafe in tree, but that is a separate discussion.)
>
> @joshtriplett mentioned that changing this lint needs a lang FCP https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVM.20alignment.20of.20i128/near/398422037. cc @maurer
>
> Reference change from when I was testing [rust-lang/rust@c742908](https://github.com/rust-lang/rust/commit/c742908c4b9abde264b8c5e9663e31c649a47f2f)
TC: Josh nominates this for our discussion. What do we think?
### "`is` operator for pattern-matching and binding" rfcs#3573
**Link:** https://github.com/rust-lang/rfcs/pull/3573
TC: Josh proposes for us that we should accept:
```rust
if an_option is Some(x) && x > 3 {
println!("{x}");
}
```
And:
```rust
func(x is Some(y) && y > 3);
```
TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.
TC: In the 2024-02-21 meeting (with limited attendance), we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.
TC: What do we think, as a gut check?
### "Unsafe fields" rfcs#3458
**Link:** https://github.com/rust-lang/rfcs/pull/3458
TC: Nearly ten years ago, on 2014-10-09, pnkfelix proposed unsafe fields in RFC 381:
https://github.com/rust-lang/rfcs/issues/381
On 2017-05-04, Niko commented:
> I am pretty strongly in favor of unsafe fields at this point. The only thing that holds me back is some desire to think a bit more about the "unsafe" model more generally.
Then, in 2023, Jacob Pratt refreshed this proposal with RFC 3458. It proposes that:
> Fields may be declared `unsafe`. Unsafe fields may only be mutated (excluding interior mutability) or initialized in an unsafe context. Reading the value of an unsafe field may occur in either safe or unsafe contexts. An unsafe field may be relied upon as a safety invariant in other unsafe code.
E.g.:
```rust
struct Foo {
safe_field: u32,
/// Safety: Value must be an odd number.
unsafe unsafe_field: u32,
}
// Unsafe field initialization requires an `unsafe` block.
// Safety: `unsafe_field` is odd.
let mut foo = unsafe {
Foo {
safe_field: 0,
unsafe_field: 1,
}
};
```
On 2024-05-21, Niko nominated this for us:
> I'd like to nominate this RFC for discussion. I've not read the details of the thread but I think the concept of unsafe fields is something that comes up continuously and some version of it is worth doing.
TC: What do we think?
### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556
**Link:** https://github.com/rust-lang/rfcs/pull/3556
TC: This seems to be about making the following work:
```rust
// kind is optional if it's been specified elsewhere, e.g. via the `-l` flag to rustc
#[link(name="ext", kind="static")]
extern {
#[no_mangle]
pub fn foo();
#[no_mangle]
pub static bar: std::ffi::c_int;
}
```
There are apparently use cases for this.
What's interesting is that apparently it already does, but we issue a warning that is wrong:
```rust
warning: `#[no_mangle]` has no effect on a foreign function
--> src/lib.rs:21:5
|
21 | #[no_mangle]
| ^^^^^^^^^^^^ help: remove this attribute
22 | pub fn foo_rfc3556_pub_with_no_mangle();
| ---------------------------------------- foreign function
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: symbol names in extern blocks are not mangled
```
TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).
TC: What do we think?
### "Better errors with bad/missing identifiers in MBEs" rust#118939
**Link:** https://github.com/rust-lang/rust/pull/118939
TC: The idea here seems to be to improve some diagnostics around `macro_rules`, but this seems to be done by way of reserving the `macro_rules` token more widely, which is a breaking change. Petrochenkov has objected to it on that basis, given that reserving `macro_rules` minimally has been the intention since we hope it will one day disappear in favor of `macro`. What do we think?
### "Uplift `clippy::invalid_null_ptr_usage` lint" rust#119220
**Link:** https://github.com/rust-lang/rust/pull/119220
TC: Urgau proposes this for us:
> This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
>
> ## `invalid_null_ptr_usages`
>
> (deny-by-default)
>
> The `invalid_null_ptr_usages` lint checks for invalid usage of null pointers.
>
> ### Example
>
```rust
// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }
```
>
> Produces:
>
```
error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
--> $DIR/invalid_null_ptr_usages.rs:14:23
|
LL | let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
| |
| help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`
```
>
> ### Explanation
>
> Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.
>
> The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.
TC: What do we think?
### "Uplift `clippy::double_neg` lint as `double_negations`" rust#126604
**Link:** https://github.com/rust-lang/rust/pull/126604
TC: This proposes to lint against cases like this:
```
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
TC: What do we think?
### "Language vs. implementation threat models and implications for TypeId collision resistance" rust#129030
**Link:** https://github.com/rust-lang/rust/issues/129030
TC: We use SipHash-1-3-128 in Rust for hashing types to form TypeIds. If these TypeIds collide in a single program, UB may result.
If SipHash-1-3-128 is a secure PRF, then the probability of such collisions happening accidentally in a program that contains an enormous 1M types is one in 2^-89.
But, if someone wanted to brute-force a collision -- that is, find two entirely random types that would have the same TypeId -- the work factor for that is no more than about 2^64 on average.
The question being nominated for lang is whether we consider that good enough for soundness, for now.
TC: What do we think?
### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251
**Link:** https://github.com/rust-lang/lang-team/issues/251
TC: This issue was raised due to discussion in a T-libs-api call. Josh gives the context:
> In discussion of [rust-lang/libs-team#325](https://github.com/rust-lang/libs-team/issues/325) (a proposal for a compile-time assert macro), the idea came up to allow `const {}` blocks at item level, and then have people use `const { assert!(...) }`.
>
> @rust-lang/libs-api would like some guidance from @rust-lang/lang about whether lang is open to toplevel `const { ... }` blocks like this, which would influence whether we want to add a compile-time assert macro, as well as what we want to call it (e.g. `static_assert!` vs `const_assert!` vs some other name).
>
> Filing this issue to discuss in a lang meeting. This issue is _not_ seeking any hard commitment to add such a construct, just doing a temperature check.
CAD97 noted:
> To ensure that it's noted: if both item and expression `const` blocks are valid in the same position (i.e. in statement position), a rule to disambiguate would be needed (like for statement versus expression `if`-`else`). IMO it would be quite unfortunate for item-level `const` blocks to be evaluated pre-mono if that same `const` block but statement-level would be evaluated post-mono.
>
> Additionally: since `const { assert!(...) }` is post-mono (due to using the generic context), it's potentially desirable to push people towards using `const _: () = assert!(...);` (which is pre-mono) whenever possible (not capturing generics).
TC: What do we think?
### "RFC: inherent trait implementation" rfcs#2375
**Link:** https://github.com/rust-lang/rfcs/pull/2375
TC: We had a design meeting on 2023-09-12 about inherent trait impls. In that meeting, I proposed a `use` syntax for this:
> In the discussion above, we had left two major items unresolved.
>
> - How do we make blanket trait impls inherent?
> - How can we allow only *some* items from the trait impl to be made inherent?
> - This is especially tricky for associated functions and methods with a default implementation.
>
> (Part of the motivation for wanting to allow only some items to be made inherent is to prevent or to fix breakage caused when a trait later adds a new method with a default implementation whose name conflicts with the name of an existing inherent method.)
>
> Coming up with a syntax for these that combines well with the `#[inherent]` attribute could be challenging.
>
> One alternative that would make solving these problems straightforward is to add some syntax to the inherent `impl` block for the type. Given the desugaring in the RFC, there is some conceptual appeal here. (quaternic proposed this arrangement; TC is proposing the concrete syntax.)
>
> We can use `use` syntax to make this concise and intuitive.
>
> Here's an example:
```rust
trait Trait1<Tag, T> {
fn method0(&self) -> u8 { 0 }
fn method1(&self) -> u8 { 1 }
}
trait Trait2<Tag, T> {
fn method2(&self) -> u8 { 2 }
fn method3(&self) -> u8 { 3 }
fn method4(&self) -> u8 { 4 }
}
struct Tag;
struct Foo<T>(T);
impl<T> Foo<T> {
// All methods and associated items of Trait1 become inherent,
// except for `method0`. The inherent items are only visible
// within this crate.
pub(crate) use Trait1<Tag, T>::*;
// Only `method2` and `method3` on Trait2 become inherent.
pub use Trait2<Tag, T>::{method2, method3};
fn method0(&self) -> u64 { u64::MAX }
}
impl<T> Trait1<Tag, T> for Foo<T> {}
impl<U: Trait1<Tag, T>, T> Trait2<Tag, T> for U {}
```
> This solves another problem that we discussed above. How do we prevent breakage in downstream crates when a trait later adds a new method with a default implementation? Since a downstream crate might have made an impl of this trait for some local type inherent and might have an inherent method with a conflicting name, this could be breaking.
>
> We already handle this correctly for `use` declarations with wildcards. Any locally-defined items override an item that would otherwise be brought into scope with a wildcard import. We can reuse that same behavior and intuition here. When a wildcard is used to make all items in the trait inherent, any locally-defined inherent items in the `impl` prevent those items from the trait with the same name from being made inherent.
>
> Advantages:
>
> - It provides a syntax for adopting as inherent a blanket implementation of a trait for the type.
> - It provides a syntax for specifying which methods should become inherent, including methods with default implementations.
> - The wildcard import (`use Trait::*`) makes it very intuitive what exactly is happening and what exactly your API is promising.
> - The `use` syntax makes it natural for a locally-defined item to override an item from the wildcard import because that's exactly how other `use` declarations work.
> - `rust-analyzer` would probably support expanding a wildcard `use Trait::*` to an explicit `use Trait::{ .. }` just as it does for other `use` declarations, which would help people to avoid breakage.
> - We can support any visibility (e.g. `use`, `pub use`, `pub(crate) use`, etc.) for the items made inherent.
>
> Disadvantages:
>
> - There's some redundancy, especially when the items to make inherent are specifically named.
During the meeting, this emerged as the presumptive favorite, and we took on a TODO item to updated the RFC.
After follow-on discussion in Zulip, Niko agreed, and also raised a good question:
> Per the discussion on zulip, I have become convinced that it would be better to make this feature use the syntax `use`, like:
>
```rust
impl SomeType {
pub use SomeTrait::*; // re-export the methods for the trait implementation
}
```
>
> This syntax has a few advantages:
>
> * We can give preference to explicit method declared in the impl blocks over glob re-exports, eliminating one source of breakage (i.e., trait adds a method with a name that overlaps one of the inherent methods defined on `SomeType`)
> * Can make just specific methods (not all of them) inherent.
> * Easier to see the inherent method when scanning source.
> * You can re-export with different visibility levels (e.g., `pub(crate)`)
> * It would work best if we planned to permit `use SomeTrait::some_method;` as a way to import methods as standalone fns, but I wish we did that.
>
> However, in writing this, I realize an obvious disadvantage -- if the trait has more generics and things, it's not obvious how those should map. i.e., consider
>
```rust
struct MyType<T> {
}
impl<T> MyType<T> {
pub use MyTrait::foo;
}
impl<T: Debug> MyTrait for MyType<T> {
fn foo(&self) { }
}
```
>
> This would be weird -- is this an error, because the impl block says it's for all `T`? And what if it were `trait MyTRait<X>`?
TC: My sense is that we've just been awaiting someone digging in and updating the RFC here.
### "Raw Keywords" rfcs#3098
**Link:** https://github.com/rust-lang/rfcs/pull/3098
TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as `k#keyword`, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).
TC: Somewhat amusingly, however, we never in fact accepted that RFC. Back in 2021, we accepted scottmcm's proposal to **cancel**:
> We discussed this RFC again in the lang team triage meeting today.
>
> For the short-term goal of the reservation for the edition, we'll be moving forward on #3101 instead. As such, we wanted to leave more time for conversations about this one, and maybe use crater results from 3101 to make design changes,
>
> @rfcbot cancel
Instead we accepted RFC 3101 that reserved `ident#foo`, `ident"foo"`, `ident'f'`, and `ident#123` starting in the 2023 edition.
Reading through the history, here's what I see:
- What do we want to do about Rust 2015 and Rust 2018? It's a breaking change to add this there. Is this OK? Do we want to do a crater run on this?
- Would we have the stomach to actually do this? It's one thing to *say* that if we wanted to use a new keyword within an edition, we'd write `k#keyword`, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic. Would we follow through?
TC: What do we think?
### "RFC: Implementable trait aliases" rfcs#3437
**Link:** https://github.com/rust-lang/rfcs/pull/3437
TC: We discussed this in the lang planning meeting in June, and it looks like there have been updates since we last looked at this, so it's time for us to have another look since we seemed interested in this happening.
TC: What do we think?
### "Should Rust still ignore SIGPIPE by default?" rust#62569
**Link:** https://github.com/rust-lang/rust/issues/62569
TC: Prior to `main()` being executed, the Rust startup code makes a syscall to change the handling of `SIGPIPE`. Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things like `seccomp` filters must be adjusted for this.
It's also just, in a practical sense, wrong for most CLI applications.
This seems to have been added back when Rust had green threads and then forgotten about. But it's been an ongoing footgun.
Making a celebrity appearance, Rich Felker, the author of MUSL libc, notes:
> As long as Rust is changing signal dispositions inside init code in a way that the application cannot suppress or undo, it is _fundamentally unusable to implement standard unix utilities that run child processes_ or anything that needs to preserve the signal dispositions it was invoked with and pass them on to children. Changing inheritable process state behind the application's back is just unbelievably bad behavior and does not belong in a language runtime for a serious language...
>
> As an example, if you implement `find` in Rust, the `-exec` option will invoke its commands with `SIGPIPE` set to `SIG_IGN`, so that they will not properly terminate on broken pipe. But if you just made it set `SIGPIPE` to `SIG_DFL` before invoking the commands, now it would be broken in the case where the invoking user intentionally set `SIGPIPE` to `SIG_IGN` so that the commands would not die on broken pipe.
There was discussion in 2019 about fixing this over an edition, but nothing came of it.
Are we interested in fixing it over this one?
Strawman (horrible) proposal: We could stop making this pre-main syscall in Rust 2024 and have `cargo fix` insert this syscall at the start of every `main` function.
(In partial defense of the strawman, it gets us directly to the arguably best end result while having an automatic semantics-preserving edition migration and it avoids the concerns about lang/libs coupling that Mara raised. The edition migration could add a comment above this inserted code telling people under what circumstances they should either keep or delete the added line.)
### "types team / lang team interaction" rust#116557
**Link:** https://github.com/rust-lang/rust/issues/116557
TC: nikomatsakis nominated this:
> We had some discussion about types/lang team interaction. We concluded a few things:
>
> * Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
> * It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
>
> Action items:
>
> * We should fix triagebot to track closed issues.
TC: What do we think?
### "[RFC] `core::marker::Freeze` in bounds" rfcs#3633
**Link:** https://github.com/rust-lang/rfcs/pull/3633
TC: There's a proposal on the table for the stabilization of the `Freeze` trait in bounds.
We discussed this in our design meeting on 2024-07-24.
TC: What's next here?
### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418
**Link:** https://github.com/rust-lang/rust/pull/106418
TC: We discussed this last in the meeting on 2024-03-13. scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:
> I remain concerned about exposing this with no opt-out on an unrestricted generic type @rfcbot concern overly-broad
>
> I'm committing to making an alternative proposal because I shouldn't block without one. Please hold my feet to the fire if that's no up in a week.
>
> Basically, I have an idea for how we might be able to do this, from [#106418 (comment)](https://github.com/rust-lang/rust/pull/106418#issuecomment-1698887324)
>
> > 2. Expose the variant ordering privately, only accessible by the type owner/module.
> >
> > Solution 2. is obviously more desirable, but AFAIK Rust can't do that and there is no proposal to add a feature like that.
https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151
### "Fallout from expansion of redundant import checking" rust#121708
**Link:** https://github.com/rust-lang/rust/issues/121708
TC: We discussed this in the meeting on 2024-03-13. The feelings expressed included:
- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
- Had a machine-applicable fix.
- Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
- Prevent potentially-disruptive changes from hitting master.
- Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.
TC: tmandry volunteered to draft a policy proposal.
### "What are the guarantees around which constants (and callees) in a function get monomorphized?" rust#122301
**Link:** https://github.com/rust-lang/rust/issues/122301
TC: The8472 asks whether this code, which compiles today, can be relied upon:
```rust
const fn panic<T>() {
struct W<T>(T);
impl<T> W<T> {
const C: () = panic!();
}
W::<T>::C
}
struct Invoke<T, const N: usize>(T);
impl<T, const N: usize> Invoke<T, N> {
const C: () = match N {
0 => (),
// Not called for `N == 0`, so not monomorphized.
_ => panic::<T>(),
};
}
fn main() {
let _x = Invoke::<(), 0>::C;
}
```
The8472 notes that this is a useful property and that there are use cases for this in the compiler and the standard library, at least unless or until we adopt something like `const if`:
https://github.com/rust-lang/rfcs/issues/3582
RalfJ has pointed out to The8472 that the current behavior might not be intentional and notes:
> It's not opt-dependent, but it's also unclear how we want to resolve the opt-dependent issue. Some [proposals](https://github.com/rust-lang/rust/issues/122814#issuecomment-2015090501) involve also walking all items "mentioned" in a const. That would be in direct conflict with your goal here I think. To be clear I think that's a weakness of those proposals. But if that turns out to be the only viable strategy then we'll have to decide what we want more: using `const` tricks to control what gets monomorphized, or not having optimization-dependent errors.
>
> One crucial part of this construction is that everything involved is generic. If somewhere in the two "branches" you end up calling a monomorphic function, then that may have its constants evaluated even if it is in the "dead" branch -- or it may not, it depends on which functions are deemed cross-crate-inlinable. That's basically what #122814 is about.
TC: The question to us is whether we want to guarantee this behavior. What do we think?
### "Policy for lint expansions" rust#122759
**Link:** https://github.com/rust-lang/rust/issues/122759
TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:
"Fallout from expansion of redundant import checking"
https://github.com/rust-lang/rust/issues/121708
During the call, the thoughts expressed included:
- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
- Had a machine-applicable fix.
- Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
- Prevent potentially-disruptive changes from hitting master.
- Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.
TC: tmandry volunteered to draft a policy proposal. He's now written up this proposal in this issue.
TC: What do we think?
### "Decide on path forward for attributes on expressions" rust#127436
**Link:** https://github.com/rust-lang/rust/issues/127436
TC: We decided recently to unblock progress on attributes on expressions (RFC 16) by allowing attributes on blocks. We have a proposed FCP to this effect.
After we did this, the question came up what we want to do about attributes in list contexts, e.g.:
```rust
call(#[foo] { block1 }, #[bar] { block2 })
```
...in particular, macro attributes.
Petrochenkov says:
> It needs to be decided how proc macros see the commas, or other separators in similar cases.
>
> Ideally proc macros should be able to turn 1 expression into multiple (including 0) expressions in this position, similarly to `cfg`s or macros in list contexts without separators. So it would be reasonable if the separators were included into both input and output tokens streams (there are probably other alternatives, but they do not fit into the token-based model as well). The "reparse context" bit from [#61733 (comment)](https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449) is likely relevant to this case as well.
We filed a concern to figure this all out.
We discussed this on 2024-07-24 and came up with these options:
> Options ordered from least to most conservative (and then from most to least expressive):
>
> - Option A: Punt this case and don't support attributes in this position without parens (e.g. `call((#[attr] arg), (#[attr] arg2))`)
> - Option B (exactly one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to a single expresion (not zero tokens, and no tokens following in the output).
> - Option C (zero or one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to zero tokens or an expression with nothing following (extra tokens, including `,`, are an error for now)
> - Option D (zero or more): Specify that an attribute in this position can expand to tokens that may include a `,`, and that if they expand to zero tokens then we elide the comma.
> - Option E (flexible): include comma, let macro decide, etc
> - We find it surprising that comma would be included.
In discussion, we seemed generally interested in allowing at least zero and 1. We weren't sure about N, and we weren't sure about the handling of the comma in the input.
TC: What do we think?
### "Decide on bounds syntax for async closures (RFC 3668)" rust#128129
**Link:** https://github.com/rust-lang/rust/issues/128129
In the special design meeting 2024-07-23, we discussed five syntaxes for async closures:
- `F: async FnMut() -> T`
- `F: AsyncFnMut() -> T`
- `F: async mut fn() -> T`
- `F: async mut () -> T`
- `F: async mut || -> T`
Our current straw poll is:
| name | `async Fn*() -> T` | `AsyncFn*() -> T` | `async fn * () -> T` | `async * () -> T` | `async * \|A, B\| -> T` |
|--------------|--------------------|-------------------|----------------------|-------------------|-------------------------|
| nikomatsakis | +1 | +0 | -1 | -1 | -1 |
| tmandry | +1 | +1 | -0.5 | -1 | -0.5 |
| Josh | -1 | +0.75 | +0.5 | +1 | +0.5 |
| pnkfelix | +0 | -0 | -0.5 | +0 | -1 |
| scottmcm | | | | | |
| TC | +1 | -0.5 | -1 | -1 | -1 |
| CE | +1 | -1 | -1 | -0.5 | -1 |
| eholk | +1 | +0 | -1 | -0.75 | -0.5 |
- +1: "This is what I would do."
- +0: "I'm OK with this, leaning positive."
- -0: "I'm neutral to this, leaning negative."
- -1: "I would block this."
We agreed to:
- Move this to an unresolved question in RFC 3668.
- Allow that RFC to proceed to FCP.
- Implement both of the two main syntax options in nightly.
- Give both syntaxes equal billing in any blog posts about this.
There was substantial discussion of this after the design meeting itself in the thread here:
https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-07-23
TC: This is just an FYI for those that didn't follow this closely.
## Action item review
- [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
### "Add soqb`s design doc to variadics notes" lang-team#236
**Link:** https://github.com/rust-lang/lang-team/pull/236
### "Update auto traits design notes with recent discussion" lang-team#237
**Link:** https://github.com/rust-lang/lang-team/pull/237
### "Update hackmd link to a public link" lang-team#258
**Link:** https://github.com/rust-lang/lang-team/pull/258
### "Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267
**Link:** https://github.com/rust-lang/lang-team/pull/267
### "text describing how other teams are enabled to make decisions." lang-team#290
**Link:** https://github.com/rust-lang/lang-team/pull/290
## RFCs waiting to be merged
None.
## `S-waiting-on-team`
### "Stabilize `extended_varargs_abi_support`" rust#116161
**Link:** https://github.com/rust-lang/rust/pull/116161
### "Emit error when calling/declaring functions with vectors that require missing target feature" rust#127731
**Link:** https://github.com/rust-lang/rust/pull/127731
### "Lint against getting pointers from immediately dropped temporaries" rust#128985
**Link:** https://github.com/rust-lang/rust/pull/128985
### "`repr(tag = ...)` for type aliases" rfcs#3659
**Link:** https://github.com/rust-lang/rfcs/pull/3659
### "Stabilize `count`, `ignore`, `index`, and `len` (`macro_metavar_expr`)" rust#122808
**Link:** https://github.com/rust-lang/rust/pull/122808
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
**Link:** https://github.com/rust-lang/rust/pull/107378
### "Emit a warning if a `match` is too complex" rust#122685
**Link:** https://github.com/rust-lang/rust/pull/122685
### "Better errors with bad/missing identifiers in MBEs" rust#118939
**Link:** https://github.com/rust-lang/rust/pull/118939
### "Uplift `clippy::double_neg` lint as `double_negations`" rust#126604
**Link:** https://github.com/rust-lang/rust/pull/126604
### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550
**Link:** https://github.com/rust-lang/rust/pull/119550
### "Implement RFC 3349, mixed utf8 literals" rust#120286
**Link:** https://github.com/rust-lang/rust/pull/120286
### "Stabilize s390x inline assembly" rust#131258
**Link:** https://github.com/rust-lang/rust/pull/131258
## Proposed FCPs
**Check your boxes!**
### "Tracking Issue for `ptr::fn_addr_eq`" rust#129322
**Link:** https://github.com/rust-lang/rust/issues/129322
### "Supertrait item shadowing v2" rfcs#3624
**Link:** https://github.com/rust-lang/rfcs/pull/3624
### "Tracking issue for const `<*const T>::is_null`" rust#74939
**Link:** https://github.com/rust-lang/rust/issues/74939
### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641
**Link:** https://github.com/rust-lang/rfcs/pull/3641
### "`repr(tag = ...)` for type aliases" rfcs#3659
**Link:** https://github.com/rust-lang/rfcs/pull/3659
### "Tracking Issue for enum access in offset_of" rust#120141
**Link:** https://github.com/rust-lang/rust/issues/120141
### "#[inline(never)] does not work for async functions" rust#129347
**Link:** https://github.com/rust-lang/rust/issues/129347
### "Decide on name for `Freeze`" rust#131401
**Link:** https://github.com/rust-lang/rust/issues/131401
### "Stabilize `count`, `ignore`, `index`, and `len` (`macro_metavar_expr`)" rust#122808
**Link:** https://github.com/rust-lang/rust/pull/122808
### "Add support for `use Trait::func`" rfcs#3591
**Link:** https://github.com/rust-lang/rfcs/pull/3591
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
**Link:** https://github.com/rust-lang/rust/pull/107378
### "[RFC] externally implementable functions" rfcs#3632
**Link:** https://github.com/rust-lang/rfcs/pull/3632
### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418
**Link:** https://github.com/rust-lang/rust/pull/106418
### "Policy for lint expansions" rust#122759
**Link:** https://github.com/rust-lang/rust/issues/122759
### "Decide on path forward for attributes on expressions" rust#127436
**Link:** https://github.com/rust-lang/rust/issues/127436
### "Don't allow unwinding from Drop impls" rfcs#3288
**Link:** https://github.com/rust-lang/rfcs/pull/3288
### "Add text for the CFG OS Version RFC" rfcs#3379
**Link:** https://github.com/rust-lang/rfcs/pull/3379
### "Stabilize associated type position impl Trait (ATPIT)" rust#120700
**Link:** https://github.com/rust-lang/rust/pull/120700
## Active FCPs
### "Trait method impl restrictions" rfcs#3678
**Link:** https://github.com/rust-lang/rfcs/pull/3678
### "Lint against `&T` to `&mut T` and `&T` to `&UnsafeCell<T>` transmutes" rust#128351
**Link:** https://github.com/rust-lang/rust/pull/128351
### "Lint against getting pointers from immediately dropped temporaries" rust#128985
**Link:** https://github.com/rust-lang/rust/pull/128985
### "Consider deprecation of UB-happy `static mut`" rust#53639
**Link:** https://github.com/rust-lang/rust/issues/53639
### "Add lint against function pointer comparisons" rust#118833
**Link:** https://github.com/rust-lang/rust/pull/118833
### "[RFC] Default field values" rfcs#3681
**Link:** https://github.com/rust-lang/rfcs/pull/3681
## P-critical issues
None.
Sign in with Wallet
Connect another wallet