Try   HackMD

T-lang meeting agenda

  • Meeting date: 2023-09-12

Attendance

  • Team members: Josh, pnkfelix
  • Others: TC, Lokathor, waffle, Urgau

Meeting roles

  • Minutes, driver: TC

Summary

  • We scheduled the following upcoming design meetings:

  • In #115659, @Michael Goulet (compiler-errors) has proposed #[feature(impl_trait_projections)] for stabilization. This feature gate had been separated off for implementation reasons. It's now relevant to the stabilization of RPITIT. We decided that T-lang had already signed off on the language concerns here, so this stabilization does not need further T-lang approval.

  • In #80926, @RalfJ had proposed to remove the aligned-in-packed check. We agreed that this should be done, and also agreed that a best-effort lint would be good, but that removing the check does not need to block on this.

  • #112380 proposes an allow-by-default unit_bindings lint that would fire when an expression of unit type is bound to a variable without the type being annotated. The exemplar of the pattern we want to catch is let list = list.sort(). The consensus was that this is a good idea, and we proposed FCP merge. We tagged this for inclusion in the release notes as we want to raise awareness of this change so that proc macro authors can make any needed adjustments. After some time, we hope to make this warn-by-default.

Scheduled meetings

  • No pending proposals this time.

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

Announcements or custom items

Finalize 2023-09 design meeting schedule

The RFCs we're considering for design meetings this month are:

TC: Based on the feedback in the thread, I would propose:

Speculatively, looking forward to October and November we might consider:

(Discussion related to who might be where when and who might want to be present for what…)

Consensus: Let's schedule the following meetings for this month:

pnkfelix: I'll update the schedule on GitHub and in the Google calendar.

Nominated RFCs, PRs and issues

"Stabilize impl_trait_projections" rust#115659

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

TC: CE nominated this:

This allows us to mention Self and T::Assoc in async fn and return-position impl Trait, as you would expect you'd be able to.

TC: This is related to the RPITIT stabilization. This feature flag was split out for implementation reasons; T-lang never decided that this should be separate.

Josh / pnkfelix: We don't need to approve removing a split we did not create.

TC: Want to pull T-lang off of the FCP?

Josh: I've removed the T-lang label and I'll write a comment to summarize.

Consensus: T-lang doesn't need to approve this.

"Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024" rust#112038

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

TC: In the 2023-09-05 meeting, we agreed this was covered by a previous FCP and that we were still happy with the decision.

TC: I propose we remove the nomination.

Josh: Agreed. I'll remove it.

Consensus: Let's remove the nomination.

"closure field capturing: don't depend on alignment of packed fields" rust#115315

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

TC: In the 2023-09-05 meeting, we agreed this was a bug fix and proposed FCP merge. It's now in FCP.

TC: I propose we remove the nomination.

Josh: Agreed. I'll remove it.

Consensus: Let's remove the nomination.

"we reserve the right to reduce our amount of UB" reference#1397

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

TC: We discussed on 2023-09-05 and proposed FCP merge. It has now entered FCP.

TC: The bot couldn't add the label. We should do that.

Josh: Done.

Josh: I'll follow up with Ralf about the unmerged suggestion.

"Handling of packed fields causes semver hazard: layout details from other crates affect type-checking" rust#115305

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

TC: We discussed in the 2023-09-05 meeting and left a comment encouraging a proposal accompanied by a crater run.

TC: I propose we remove the nomination and allow it to be re-nominated when a proposal has been made.

Josh: Someone would have to make a proposal for concrete lints and then run crater on that.

Josh: We can safely remove the nomination. I'll remove it.

Consensus: Let's remove the nomination pending a proposal.

"Aligned-in-packed restriction can be circumvented with generic parameters" rust#80926

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

TC: RalfJ nominated this:

I feel like we should just remove the aligned-in-packed check. There's probably already code out there relying on its current behavior via generics (even accidentally). And I don't think the behavior is particularly surprising either, packed acts on align types the same way it acts on all types – it completely ignores their alignment.

Having types that can be written with generics but not monomorphic is obviously inconsistent, and means the check can at best serve as a lint anyway. We had a similar situation with repr(transparent) and that got fixed by also allowing the attribute on types where all fields are 1-ZST.

I wonder what @rust-lang/lang thinks about this – the original goal was to avoid having to decide either way for the interaction of packed and align. Different C implementations seem to behave differently: on MSVC, __declspec(align(N)) types are fully aligned even in a packed struct; in GCC __attribute__((aligned(N))) types behave like all other types in a packed struct. But now that we inadvertently already made a decision to behave like GCC, is it really worth keeping the restriction?

Lokathor: What a mess that sounds like.

Josh: It's becoming clear packed is a good example of something that should be or should have been an unsafe attribute.

pnkfelix: It's not inherently unsound until it is.

Lokathor: In that sense, it is like no_mangle. It's not unsafe unless you mix it with other things.

TC: What do we think that Ralf is asking for exactly? People here seem to agree that this is a mess.

Josh: The check isn't as effective as we thought it would be. It may not have a lot of value. Ralf is saying it does the same thing on align as it does on everything else: "I don't care what alignment these types want, pack them anyway". That seems like a reasonable argument. It's not clear we need a check here about two things that are inconsistent.

Lokathor: Maybe the rule should be "outermost wins".

Josh: I think the rule is outermost wins at the moment.

Lokathor: If we remove the check, that codifies that rule.

pnkfelix: I'm trying to figure out if downgrading to a lint even has any value.

Josh: My only concern is the third paragraph, about GCC's behavior. But I don't think this particularly makes that worse. We could always make it better in the future.

Lokathor: If you had to be compatible here, you could cfg flag it.

Josh: Keeping this check doesn't seem valuable.

pnkfelix: Do we think it has any value as a lint?

pnkfelix: We're going to allow an aligned attribute that won't mean anything. It's like dead code.

Josh: Sticking aligned on a struct and putting the struct in a packed thing, it may not be totally dead, because you could be using the struct elsewhere.

Josh: But we could have a best effort lint.

pnkfelix: And it doesn't need to block removing the check.

Josh: +1 on that.

Lokathor: Maybe the lint should live in clippy, since it's known to be less accurate.

pnkfelix: I'll write the comment.

Consensus: Let's remove the check. We're in favor of a best-effort lint, but the check can be removed without that lint being implemented.

"Add allow-by-default lint for unit bindings" rust#112380

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

TC: WaffleLapkin nominated this:

Nominating for T-lang discussion, as they are usually the ones approving lints.

The current lint behavior is described in the PR description. It's designed in such a way that there shouldn't be many false positives (is this the right term? I'm always confusing them…) — as using an explicit unit type, a () pattern or a () expression will silence the lint.

The only false positive really possible is the case of proc macro using a user provided span for the unit binding. There isn't much to do here and this seems to be an issue with the proc macro implementation, not the lint. See this comment for details: #112380 (comment).

The question(s) for the lang team: do we want to include such lint in the compiler? Is the current behavior the one we want? What should be the default level of this lint (allow, warn…)?

TC: Waffle, you're here, want to fill us in?

(Waffle discusses the situation…)

waffle: There is a possible false-positive in certain macro use-cases where code is generated with spans.

Lokathor: Looking at that, I'm not sure as a user I'd know how to silence that lint.

…

Lokathor: I guess the proc macros should update what they're doing.

TC: What should the proc macros do instead?

waffle: They should properly say which tokens are being generated by them rather than being taken from the macro call itself.

TC: We had earlier discussed sort as a good example of the value of this lint. Let's write that down.

waffle/TC:

// classic problem, `sort` uses `&mut self` it doesn't return
// a newly sorted list
let list = list.sort();

// Would not lint:
let list: () = list.sort();
let _: () = list.sort();
let () = list.sort();

// Would still lint:
let _ = list.sort();

Josh: It would be worth turning this up and doing a crater run. We might consider turning this up to default warn.

TC: There was a crater run done on 2023-06-29.

Josh: I'm surprised by point 7 there (let mut _ = expr). This isn't legal code.

  1. Lints fired on let mut? _ = expr: 6154

waffle: This may have been a copy-paste error in the analysis. So it's just let _ without mut.

TC: It sounds like the consensus is that this is a good idea. What's the next step?

Lokathor: Starting an FCP.

Josh: I'll propose T-lang FCP merge.

waffle: So we'll allow-by-default, suggest the changes to the proc macros, then later warn-by-default?

Josh / Lokathor: Yes.

Josh: We may want to draw attention to it, e.g. with a blog post on inside Rust.

Lokathor: Can we tag it for special mention in the release notes?

Josh: Tag it relnotes. I'll do that.

Consensus: Let's propose FCP merge. We'll tag this for inclusion in the release notes. The plan is to make this warn-by-default after some time.

Josh: Side-note. Someone brought this up to me as surprising:

x; // drops x

waffle: We already have a lint for that. It's on by default. Here's the example: playground link.

The lint is: #[warn(path_statements)]

(The meeting ended here.)

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

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

TC: This had been waiting on author. The author then updated. Both Josh and pnkfelix have resolved their concerns. This is now waiting on one checkbox to enter FCP.

"Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

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

TC: Based on feedback from t-lang, @xFrednet created a list of use-cases and is seeking review from t-lang.

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

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

TC: The 2023-08-22 meeting consensus was to write the RFC now posted as rfcs#3477. We're also waiting for a root-cause assessment on an unexpected check build-time regression.

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

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

TC: This is in a t-compiler proposed FCP, but @jieyouxu has a specific question for t-lang.

TC: We discussed this in the meeting on 2023-07-25 without resolution.

"const-eval: make misalignment a hard error" rust#115524

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

TC: Oli nominated this:

Nominating for T-lang team discussion. Don't know if you want to FCP this, as it's already in line with the const UB RFC (if your code exhibits UB at compile-time, but passes, we are allowed to break it later)

TC: RalfJ commented:

I don't even know of an example where this is a breaking change… So crater seems unnecessary to me.

This is a kind of funny FCP since it turns out the breaking change accidentally happened in #104616, we're now just removing some dead code.

Ah, the lint docs actually have an example of code that did trigger the lint. So this is a breaking change after all.

"Object lifetime defaults of GATs are not respected" rust#115379

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

TC: fmease nominated this:

Nominating this for lang team discussion since I really don't know if this works as intended or not.

To infer the default trait object lifetime of a trait object type, we first look at the bounds on the relevant type parameter of the containing generic type. According to my interpretation of the Reference, RFC 599 and RFC 1156, any kind of generic type can be an elegible container type, not just ADTs. However, if the containing generic type is a GAT, the compiler doesn't properly take into consideration the bounds on its type parameters. The RFCs obviously predate GATs.

"MaybeDangling" rfcs#3336

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

TC: We discussed this 2023-08-22 and our consensus was to table the issue so that we could look more carefully into the situation offline. We're planning to read this RFC in an upcoming design meeting.

"Implement PartialOrd and Ord for Discriminant" rust#106418

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

TC: In the 2023-08-29 meeting we decided that we did have reservations and wanted to see what T-libs-api came back with. scottmcm left a comment in the thread to that effect. We're still waiting on the response.

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

"Tracking Issue for the Rust specification" rust#113527

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

TC: We've created a new Zulip stream for this work.

TC: A job description for the editor has been discussed. There seems to be consensus to move forward on the hiring process.

TC: There is outstanding discussion on the appropriate name of this document.

TC: There is an outstanding discussion ongoing about the goals of the specification.

TC: Niko has proposed to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements.

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

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

"Parse unnamed fields and anonymous structs or unions" rust#114782

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

TC: We agreed in the 2023-09-05 meeting that ty should not parse anonymous types.

"Guarantee representation of None in NPO" rust#115333

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

TC: In the 2023-08-29 meeting we decided to tag this with T-libs-api, untag T-libs, and propose FCP merge. tmandry has done this, and it is now waiting on checkboxes (from Niko and pnkfelix on T-lang).

"Cargo Check T-lang Policy" rfcs#3477

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

TC: We agreed on final language in the 2023-08-29 meeting. This is now entering FCP.

Action item review

Pending lang team project proposals

None.

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: The FCP merge for this is complete. It just needs to be merged.

RFCs waiting to be merged

None.

S-waiting-on-team

"Tracking issue for dyn upcasting coercion" rust#65991

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

TC: This is waiting on T-types.

"Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024" rust#112038

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

TC: This item is nominated; let's discuss it there.

"closure field capturing: don't depend on alignment of packed fields" rust#115315

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

TC: This item is nominated; let's discuss it there.

"document ABI compatibility" rust#115476

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

TC: We discussed this in the 2023-09-05 triage and in the 2023-09-06 planning meeting and were +1 on it. It's waiting on T-opsem to confirm they have reviewed it.

TC: I've asked (on 2023-09-12) T-opsem about what they want to do here.

"const-eval: make misalignment a hard error" rust#115524

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

TC: This item is nominated; let's discuss it there.

Proposed FCPs

Check your boxes!

"unsafe attributes" rfcs#3325

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

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

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    I do think we should permit br"¥¥¥", but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.

    I'm going to go ahead and propose FCP for this. This does not preclude making further changes to how this information is presented.

    @rfcbot merge

    @rfcbot concern raw-byte-strings-with-unicode

"Add f16 and f128 float types" rfcs#3453

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

    Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @Amanieu
    • @BurntSushi
    • @dtolnay
    • @joshtriplett
    • @m-ou-se
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    Since we define f32 and f64 to be IEEE binary32 and binary64, it seems entirely reasonable to also include binary16 and binary128 as well, working analogously.

    Let's see what others think:
    @rfcbot fcp merge

    Though I do expect that this will be non-trivial to stabilize, in terms of implementation effort, like how u128 was easy to RFC but very hard to make work broadly.

    Compiler folks: Please comment if you think this should be postponed as impractical to implement in the foreseeable future.

    (Practically, we might not accept f128: Display + FromStr for a while even on nightly, because of size impacts of being able to accurately print/parse such precision, for example.)

"Tracking issue for dyn upcasting coercion" rust#65991

"Stabilise inline_const" rust#104087

"Stabilize anonymous_lifetime_in_impl_trait" rust#107378

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

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:

    @rfcbot merge

    We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

"TAIT defining scope options" rust#107645

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

    Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

    We held a design meeting yesterday where we reviewed this document prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.

    The document proposed the following resolution to this issue:

    • The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
      • Functions and methods must have the hidden type that they intend to constrain within their signature – within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
      • Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
      • A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
    • The hidden type may be constrained by functions, methods, constants, and statics.

    The doc goes into more detail about the justifications and alternatives.

    Given all this, I propose to merge and accept this proposal.

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

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

    Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

    We agreed in last week's lang team meeting to FCP this. My understanding is that this removes all(?) errors that are dependent on optimization flags (e.g. debug vs release), but does not tackle the difference between check and build.

    My above comment still applies to what's being FCP'd: This FCP does not itself establish a policy that we will commit to this kind of behavior going forward. A crater run would be informative in terms of both build failure regressions and performance (if we are set up to collect performance data).

    I'm still trying to understand why there were regressions on debug builds too. I'm guessing it's because we optimized dead code out even in debug mode? That would suggest that there are going to be ecosystem crates which used to build but do not build anymore, in either debug or release.

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

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

    Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @Amanieu
    • @BurntSushi
    • @CAD97
    • @Dylan-DPC
    • @JakobDegen
    • @Mark-Simulacrum
    • @RalfJung
    • @cuviper
    • @digama0
    • @dtolnay
    • @joshtriplett
    • @m-ou-se
    • @nikomatsakis
    • @pietroalbini
    • @pnkfelix
    • @saethlin
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

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

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

    Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot merge

"Guarantee representation of None in NPO" rust#115333

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

    Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @Amanieu
    • @BurntSushi
    • @dtolnay
    • @joshtriplett
    • @m-ou-se
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge

"document ABI compatibility" rust#115476

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

    Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @joshtriplett
    • @nikomatsakis
    • @pnkfelix
    • @scottmcm
    • @tmandry

    Concerns:

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    The T-lang design team discussed this PR briefly in triage meeting.

    We agreed with @RalfJung that this is something that needs documentation, and it appears that this text is not adding anything new, but rather documenting the existing rules as they are understood. Therefore, we are happy to go ahead with a T-lang FCP.

    In addition, however, we thought that this seemed like it may overlap with the expertise of T-opsem, and therefore in addition to the T-lang FCP, we also are nominating this for T-opsem to look at to ensure that they have a chance to sign off on the text as written here.

    @rfcbot fcp merge

"Stabilize impl_trait_projections" rust#115659

  • Link: https://github.com/rust-lang/rust/pull/115659
  • Tracking Comment:

    Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:

    • @BoxyUwU
    • @aliemjay
    • @compiler-errors
    • @jackh726
    • @joshtriplett
    • @lcnr
    • @nikomatsakis
    • @oli-obk
    • @pnkfelix
    • @scottmcm
    • @spastorino
    • @tmandry

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  • Initiating Comment:

    @rfcbot fcp merge (see stabilization report above)

Active FCPs

"Cargo Check T-lang Policy" rfcs#3477

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

"closure field capturing: don't depend on alignment of packed fields" rust#115315

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

P-critical issues

None.

Last changed by 
 
Rust Lang Team
Language Design team for the Rust programming language
0
227

Read more

Lang/RfL meeting 2025-04-23

People:

Apr 23, 2025
Triage meeting 2025-04-23

Meeting date: 2025-04-23

Apr 23, 2025
Triage meeting 2025-04-16

Meeting date: 2025-04-16

Apr 16, 2025
Triage meeting 2025-04-09

Meeting date: 2025-04-09

Apr 10, 2025
Read more from Rust Lang Team
Published on HackMD