T-lang meeting agenda

• Meeting date: 2023-10-18

Attendance

• Team members: Josh Triplett (JT), Niko Matsakis (NM), Tyler Mandry (TM), scottmcm, pnkfelix (FK), TC (T-lang-ops)
• Others: waffle

Meeting roles

• Minutes, driver: TC

Scheduled meetings

• 2023-10-11: "Meeting proposal: Unsafe extern blocks" #223
• 2023-10-18: "Design meeting: Decide about the future for consts in patterns" #220
• 2023-10-25: "Design meeting: Implementable trait aliases" #224

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!)

PRs on the lang-team repo

"Add size != stride to frequently requested changes" lang-team#216

Link: https://github.com/rust-lang/lang-team/pull/216

TC: This PR has been hanging out awhile even after the FCP completed. If someone wants to flip the bit that would let me do it, I'll merge it. I'd also use that bit to start posting the minutes to GitHub.

NM: I'll flip the bit.

JT: +1. Seems sensible for the person writing the minutes to post them.

RFCs waiting to be merged

"RFC: Unicode and escape codes in literals" rfcs#3349

Link: https://github.com/rust-lang/rfcs/pull/3349

NM: I'll open an issue/PR to flip the bit.

JT: It's probably a teams repo where that needs to happen.

"Add f16 and f128 float types" rfcs#3453

Link: https://github.com/rust-lang/rfcs/pull/3453

TC: As above.

Nominated RFCs, PRs, and issues

"Make #[repr(Rust)] and #[repr(C)] incompatible with one another" rust#116829

Link: https://github.com/rust-lang/rust/pull/116829

TC: CE nominated this for us.

TC: Apparently, on beta, #[repr(C, Rust)] compiles successfully. This was nominated to confirm that we don't want that.

fmease: Further, should #[repr(Rust, simd)] be forbidden, too? #[repr(C, simd)] already gets rejected.

JT: Sure sounds like a compiler error.

pnkfelix: Do we know how long-standing this bug is?

waffle: #[repr(Rust)] was introduced in a recent PR.

JT: Probably shouldn't be able to #[repr(Rust, i8)] either?

pnkfelix: Why not?

JT: They're asking for contradictory things. repr(Rust) allows niches, repr(uN)/repr(iN).

pnkfelix: We could disallow that in the short term.

JT: The other one mentioned was #[repr(Rust, simd)].

waffle: this is currently accepted on nightly:

#[repr(Rust, u8)]
enum S {
    A, B(u8)
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3646c815ed3674d70e8a1974f04c0bcb

pnkfelix: Maybe we should enumerate what is allowed.

JT: #[repr(Rust, packed)] and #[repr(Rust, aligned(N))] are the ones that make sense for now.

scottmcm: #[repr(Rust, transparent)]?

JT: Transparent is disallowed because it disallows combining with anything else currently.

scottmcm: I'd like to kill repr(Rust, packed)…

tmandry: The nomicon says that packed does apply to #[repr(Rust)].

scottmcm: We should probably allow it (Rust, packed) even if it makes us sad.

JT: I think that reduces to "packed makes us sad".

pnkfelix: Ralf said that, looking at the code, packed is equivalent to (C, packed).

scottmcm: Maybe we should lint to tell people who write packed that they mean and should write C, packed.

JT: The reference says packed uses the "default representation" unless you say C, packed. Of course, the reference could be wrong.

waffle: We don't guarantee any representation for repr(Rust), so it always being C is OK.

scottmcm: I propose we allow it. This isn't the time/place to express our unhappiness with packed or with how we stuff reprs into the attributes.

JT:

scottmcm: As an example of the problem, we're seeing now that packed is a modifier on something but transparent is not. (And maybe it would make sense to reflect some of these differences in syntax, but this change is not the time for that.)

JT: Let's ping T-opsem to check (and to check and possibly update the reference).

waffle: I'll leave a note in the PR.

Consensus:

• Allow Rust, aligned(N).
• Allow Rust, packed.
• Disallow any other Rust, ....

"Do not inline integer literals which are out of range in format_args!" rust#116633

Link: https://github.com/rust-lang/rust/pull/116633

TC: CE nominated this for us. It seems that we accidentally stabilized this:

fn main() {
    println!("{}", 0x8Fi8); // OK?
         // prints 143 !!!!!
}

TC: The question seems to be whether we want to break it.

pnkfelix: This has been allowed since 1.70. It might have been gated then.

nikomatsakis: Is there a lint for this?

scottmcm: No, it's worse. It prints "200" for the following, which is "impossible" for i8.

fn main() {
    println!("{}", 200_i8); // OK?
}

waffle: It inlines it into the string.

TC: It's converting these to 128-bit numbers before inlining.

JT: I propose we fix this and let the usual release crater runs check it.

tmandry: +1, let's fix the bug.

Urgau: there was a crater run: https://github.com/rust-lang/rust/pull/116633#issuecomment-1761228862 (no regression found, I think)

scottmcm/pnkfelix: I can't imagine anyone would want to rely on this.

NM: It's definitely a bug.

JT: +1. Also, this is a lint that someone could turn off.

scottmcm: But it would wrap around.

scottmcm: I'll leave a comment.

Consensus: This is a bug. Let's fix it.

"Tracking Issue for const mem::discriminant" rust#69821

Link: https://github.com/rust-lang/rust/issues/69821

TC: This needs T-lang members to check off, none have yet, and it seems easy to do in this case.

JT: All four of the people with unchecked boxes are in this meeting.

tmandry: Are there any considerations to be aware of?

scottmcm: Now that we have pointer const, this isn't really exposing anything. It doesn't particulary scare me.

TC: This is now entering FCP. I'll unnominate.

Consensus: Let's do this.

"Stabilize const_maybe_uninit_zeroed and const_mem_zeroed" rust#116218

Link: https://github.com/rust-lang/rust/pull/116218

TC: Similarly, this is another constification needing T-lang attention.

scottmcm: Ralf said this one looks good. With unions in const you can already kind of do this.

tmandry: …

scottmcm: From a lang side, we could add an intrinsic for zeros.

NM: What's Ralf mean by "internal mutable reference support"?

scottmcm: It'd be bad if the caller could get the reference, but they can't, it's internal, so it's OK.

NM: I'll ask a question in the ticket.

Consensus: We'll wait to hear back on that question and discuss again.

"Guarantee char layout" reference#1401

Link: https://github.com/rust-lang/reference/pull/1401

TC: @ehuss nominated this. The question seems to be whether we're OK with this language:

Layout and bit validity

char is guaranteed to have the same size and alignment as u32 on all platforms.

JT: I'm assuming this phrasing does not preclude us from later doing move-only data types.

tmandry; If you mean string types, then I agree.

JT: If you have a char, you could do clever niche tricks that would be visible if there's a reference.

NM: You mean things to which you can't take references?

JT: Right. E.g. packing a char and three bools into a u32.

scottmcm: This reminds me of the NPO guarantee.

JT: I'd be fine with a consensus with or without the point I raised. We could leave it up to the reference folks.

JT: We don't already say this in the std docs.

JT: https://doc.rust-lang.org/std/option/index.html#representation

scottmcm: I was actually expecting a PR to the std docs. We've been FCPing other such guarantees there.

scottmcm: Maybe if we merge this, we should also then merge a PR in std.

TC: Proposal is to merge this verbatim.

NM: +1.

tmandry: And we can leave a comment that the std docs should also be updated.

Josh: I'll leave that comment.

TC: I'll unnominate.

Consensus: Let's do this. The std docs should also be updated, but that can be done separately.

"Stabilize Ratified RISC-V Target Features" rust#116485

Link: https://github.com/rust-lang/rust/pull/116485

TC: This PR stabilizes ratified RISC-V target features.

• Atomic Instructions (A) on v2.0
• Compressed Instructions © on v2.0
• Integer Multiplication and Division (M) on v2.0
• Bit Manipulations (B) on v1.0 listed as zba, zbc, zbs
• Scalar Cryptography (Zk) v1.0.1 listed as zk, zkn, zknd, zkne, zknh, zkr, zks, zksed, zksh, zkt, zbkb, zbkc zkbx

TC: @tmandry and @scottmcm have reviewed and given +1.

tmandry: I don't think there's anything controversial in this PR.

pnkfelix: What do all the crossed out things mean?

tmandry: They were removed from this stabilization discussion. This is due to how a target feature can impact the ABI.

tmandry: All of these have been approved by the RISC-V ratification process.

TC: This is going into FCP. I'll unnominate.

Consensus: Let's do this.

"Reserve gen keyword in 2024 edition and start an experiment implementation of Iterator generators " rfcs#3513

Link: https://github.com/rust-lang/rfcs/pull/3513

TC: We discussed this last week on 2023-10-10 in the context of an earlier issue. We were feeling positive about reserving the keyword in the 2024 edition given the progress, and we wanted an RFC that described what was known about how gen / iter blocks should work. We were OK with the RFC leaving undecided questions that were still open. This RFC has now been posted.

TC: This is something we need to decide ahead of the 2024 edition. Is there anything we should discuss about it this week to move forward?

TC: tmandry, you had raised a point about this phrasing itself as an e-RFC.

(Discussion about that.)

JT: We introduced the k# mechanism to allow a keyword to be used immediately. Is the rationale that we don't expect it to be stabilized before the 2024 edition?

tmandry: Correct.

NM: It'd be worth writing out our edition policies. We've resisted reserving keywords speculatively. This feels different because we know we want this for an upcoming feature.

pnkfelix: Right.

NM: We know exactly what we want to use it for, and we have high certainty on the keyword.

JT: And we have yield reserved.

NM: I don't want to reserve this and then end up with a different keyword.

JT: We do have to complete the bikeshed before the edition.

TC: Oli had revised the RFC to not use the keyword for the initial experiment to try to help the RFC land more quickly. Would we actually prefer for the RFC to just make a decision on the keyword and commit to it?

JT: Honestly yes.

NM: Kicking the can down the road isn't any good. This RFC is to hash out the keyword. Of course we can change our mind (with expense).

scottmcm: I liked niko's phrasing of "RFC is for 'how will people experience this feature'".

scottmcm: Oli could put this in the compiler with attributes without an RFC.

JT: We should go ahead and settle it. And let's reserve the keyword.

NM: Sounds good to me. Sounds like we're aligned.

waffle: I'm concerned about the section on how we handle self-referential generators. It seems to me that generators will mostly be self-referential, as futures are.

tmandry: Agreed it's an important question. But the current RFC implies that another RFC will be required.

NM: There is no way we're doing this without self borrows.

JT: We can decide at stabilization time whether there are any one-way doors.

NM: It does have those doors. This feels like something that would be an unresolved question. The RFC could list the patterns that we want to have work. It feels silly to block when we know that we'll find some solution.

TC: I'm planning to revise the RFC to remove the language requiring a new RFC. It'll be a regular RFC.

waffle: We should do this like we did with tail calls.

NM: Agreed it should be a normal RFC.

JT: Is this going to be labeled experimental?

NM: No. Experimental RFCs are a dead process. Once there's an RFC, the team has said it's in favor of that direction. The RFCs are a way to get community feedback.

TC: And I'll revise also to remove the attribute syntax and have the RFC commit to the gen keyword.

scottmcm: +1.

NM: The self-borrowing can be an unresolved question, but I wouldn't object to it being spelled out either. But either way, if we spell out the patterns that we want to make work, we could maybe eventually stabilize on that basis.

scottmcm: "We are hoping to allow self-referential generators under this framework, but might need a new RFC if it turns out to not work." But that's how implementing features goes.

Consensus: TC and Oli will revise the RFC.

• We are in favor of gen keyword.
• We want generators and we want to reserve it for 2024.
• We think we want self-borrowing generators, but we want to better understand what it means, so this should be an unresolved question and we will decide later if a follow-up RFC.
  • Ideal is to enumerate the usage patterns we know we want to work (e.g., for loop) and show what generators might mean for them.

(The meeting ended here.)

"Lifetime Capture Rules 2024" rfcs#3498

Link: https://github.com/rust-lang/rfcs/pull/3498

TC: FCP merge has been proposed. Given that RPITIT relies on this behavior and will be stabilized in Rust 1.75, it would be good to move this RFC forward before we start announcing RPITIT more widely. It's also, of course, related to the 2024 edition. Is there anything we can discuss to move this forward?

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

"Decision: semantics of the #[expect] attribute" rust#115980

Link: https://github.com/rust-lang/rust/issues/115980

TC: @nikomatsakis gives this background:

This issue is spun out from #54503 to serve as the decision issue for a specific question. The question is what the 'mental model' for the expect attribute should be. Two proposed options:

1. The expectation is fulfilled, if a #[warn] attribute in the same location would cause a diagnostic to be emitted. The suppression of this diagnostic fulfills the expectation. (src) (Current implementation in rustc)
2. The expectation is fulfilled if removing the #[expect] attribute would cause the warning to be emitted. (src)

@xFrednet created a list of use cases to help with the discussion of these two models; they found both models work equally well, except for use case 4 which would only be possible with the first model.

TC: …and proposes that we adopt option 1.

"Stabilize anonymous_lifetime_in_impl_trait" rust#107378

Link: https://github.com/rust-lang/rust/pull/107378

TC: In the 2023-10-10 meeting, we discussed this. The main open question is whether these lifetimes should be higher ranked. We decided we wanted an analysis that went deeper than just pointing out consistency with an accidental stabilization (and we were hoping to get feedback from @nikomatsakis). @tmandry has now done that analysis.

".await does not perform autoref or autoderef" rust#111546

Link: https://github.com/rust-lang/rust/issues/111546

TC: This was nominated for T-lang (and for T-types) by WG-async. @tmandry said:

We discussed this in a recent wg-async meeting (notes). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).

There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)

The main motivation for the change is the analogy to .method(), as well as to wanting async and sync to feel similarly convenient in most cases.

Note that there is another analogy that works against this, the analogy to IntoIterator, where the lang-effect form (for _ in foo {}) does not do autoref/autoderef. However, given that this looks very different from foo.await, and taking a reference with that form is significantly more convenient (for x in &foo or for x in foo.iter() vs (&foo).await), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.

That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.

"Tracking Issue for the Rust specification" rust#113527

Link: https://github.com/rust-lang/rust/issues/113527

TC: On 2023-10-12, pnkfelix posted a vision document for the Rust specification. We all might want to have a look at that.

"Support overriding warnings level for a specific lint via command line" rust#113307

Link: https://github.com/rust-lang/rust/pull/113307

TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. @jieyouxu has since replied:

I believe I wanted to ask that if the command line indeed forms the root of the tree, or if it actually overrides the source annotations.

TC: On that basis, @tmandry replied:

Nesting

I think the command line (specifically -A, -W, -D flags) should form the root of the tree. We have --cap-lints, --force-warn, and -F (forbid) for overriding the source. (Actually the mental model documented in the rustc book is that force-warn and forbid still form the root of the tree, but cannot be overridden; I think the distinction is mostly academic.)

That's almost all the expressive power one could want along this axis. One wrinkle is that --forbid is overridden by --cap-lints, while --force-warn is not. If we wanted full fine-grained control we could always add --force-allow and --force-deny.

warnings

Regarding the meaning of warnings, it is a simpler mental model for this to mean "the set of things that are warn-by-default". But this ignores what I perceive to be a common (and valid) use case, which is to disallow all warnings in a codebase: In other words, prevent code from being checked in that causes warnings to be printed to a user's screen. Of course, for this to be practical one must control the version of rustc being used to build a codebase, but that is common in monorepo setups.

Conclusion

Given that there is an existing use case that relies on documented behavior, I think we should continue to treat warnings as a "redirect" for all warnings that come out of a particular level of the tree. Interpreting -Awarnings -Wfoo in the way proposed by this PR would muddy the (already complicated) mental model and add inconsistency between CLI and the command line, as noted by @oli-obk.

A different group, like default-warnings, could be used to mean "the set of things that are warn-by-default". The compiler could further warn users that specify -Awarnings -Wfoo on the command line to use -Adefault-warnings -Wfoo instead.

"Fix non_camel_case_types for screaming single-words" rust#116389

Link: https://github.com/rust-lang/rust/pull/116389

TC: @petrochenkov nominated this for us:

A relaxed version of this PR could be bumping the length limit from 3 letters to 4. E.g. ABC would still be considered camel case, but ABCD/ABCDF/etc not.

This is related to #116336 and #60570.

"RFC: Syntax for embedding cargo-script manifests" rfcs#3503

Link: https://github.com/rust-lang/rfcs/pull/3503

TC: The following syntax is being proposed for addition to Rust:

#!/usr/bin/env cargo
```cargo
[dependencies]
clap = { version = "4.2", features = ["derive"] }
```

use clap::Parser;

"MaybeDangling" rfcs#3336

Link: https://github.com/rust-lang/rfcs/pull/3336

TC: We discussed this in an RFC read on 2023-09-27. The consensus was that someone would proposed FCP merge, but that has not yet been done.

"Non-temporal stores (and _mm_stream operations in stdarch) break our memory model" rust#114582

Link: https://github.com/rust-lang/rust/issues/114582

TC: We discussed this on 2023-08-15.

@RalfJ points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @scottmcm said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy."

TC: Some discussion followed about this issue after the meeting.

TC: We further discussed this in the 2023-10-10 meeting without resolution. We raised the question of whether adding a lint might be a good step forward.

"RFC: Implementable trait aliases" rfcs#3437

Link: https://github.com/rust-lang/rfcs/pull/3437

TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one.

TC: We discussed this in the 2023-09-26 triage meeting. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko has posted that comment.

"dyn Trait comparison should not include the vtable pointer" rust#106447

Link: https://github.com/rust-lang/rust/issues/106447

TC: The FCP to close this issue has been completed. However, @Amanieu is still looking for a way forward. There's been some discussion on Zulip about this.

TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding ptr::addr_eq may be one small step forward. @pnkfelix proposed this in the ticket and then to T-libs-api. @dtolnay seconded the request and asked for a PR.

"Implement PartialOrd and Ord for Discriminant" rust#106418

Link: https://github.com/rust-lang/rust/pull/106418

TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko left a comment to the effect that "right now we seem to have no good options."

TC: There has since been further discussion on the issue. E.g., Amanieu noted:

While discussing this in the libs-api meeting today, we noticed that the documentation for mem::discriminant doesn't guarantee stability for the discriminant. This means that the actual ordering of Discriminant is not tied to the source code order of the variants.

This makes it unsuitable for many use cases, including the one in the PR description, which is to manually implement Ord for an enum. To enable this use case, we need to guarantee that the ordering of Discriminant matches that of the variants in the source code.

"Disallow references to static mut [Edition Idea]" rust#114447

Link: https://github.com/rust-lang/rust/issues/114447

TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it E-help-wanted.

"Report monomorphization time errors in dead code, too" rust#112879

Link: https://github.com/rust-lang/rust/pull/112879

TC: We're waiting on @oli to investigate an unexpected incremental build-time regression. I made sure that @oli knows that, and knows that we resolved the fundamental question that was blocking this earlier in RFC 3477.

Action item review

• Action items list

Pending lang team project proposals

None.

S-waiting-on-team

"Tracking issue for dyn upcasting coercion" rust#65991

Link: https://github.com/rust-lang/rust/issues/65991

"Stabilize anonymous_lifetime_in_impl_trait" rust#107378

Link: https://github.com/rust-lang/rust/pull/107378

"remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098

Link: https://github.com/rust-lang/rust/pull/116098

Proposed FCPs

Check your boxes!

"RFC: inherent trait implementation" rfcs#2375

Link: https://github.com/rust-lang/rfcs/pull/2375

"unsafe attributes" rfcs#3325

Link: https://github.com/rust-lang/rfcs/pull/3325

"Lifetime Capture Rules 2024" rfcs#3498

Link: https://github.com/rust-lang/rfcs/pull/3498

"Tracking issue for dyn upcasting coercion" rust#65991

Link: https://github.com/rust-lang/rust/issues/65991

"Tracking Issue for const mem::discriminant" rust#69821

Link: https://github.com/rust-lang/rust/issues/69821

"Stabilise inline_const" rust#104087

Link: https://github.com/rust-lang/rust/pull/104087

"Stabilize anonymous_lifetime_in_impl_trait" rust#107378

Link: https://github.com/rust-lang/rust/pull/107378

"TAIT defining scope options" rust#107645

Link: https://github.com/rust-lang/rust/issues/107645

"Report monomorphization time errors in dead code, too" rust#112879

Link: https://github.com/rust-lang/rust/pull/112879

"FCP process: Require 2/3 majority for FCP" rust#114986

Link: https://github.com/rust-lang/rust/issues/114986

"c_unwind full stabilization request: change in extern "C" behavior" rust#115285

Link: https://github.com/rust-lang/rust/issues/115285

Active FCPs

"Guarantee representation of None in NPO" rust#115333

Link: https://github.com/rust-lang/rust/pull/115333

"document ABI compatibility" rust#115476

Link: https://github.com/rust-lang/rust/pull/115476

P-critical issues

None.