Triage meeting 2023-11-08

--- title: Triage meeting 2023-11-08 tags: T-lang, triage-meeting, minutes date: 2023-11-08 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202023-11-08 url: https://hackmd.io/QPLKCkWdRkKFNAXud550Cw --- # T-lang meeting agenda - Meeting date: 2023-11-08 ## Attendance - People: TC, tmandry, scottmcmm, nikomatsakis, Urgau, waffle, eholk ## Meeting roles - Minutes, driver: TC ## Scheduled meetings - 2023-11-08: "T-types proposal for stabilizing type alias impl Trait (TAIT)" [#233](https://github.com/rust-lang/lang-team/issues/233) - 2023-11-15: "2024 Edition Review" [#234](https://github.com/rust-lang/lang-team/issues/234) - 2023-11-29: "weak alias types for Rust 2024" [#227](https://github.com/rust-lang/lang-team/issues/227) 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!) ## Nominated RFCs, PRs, and issues ### "Stabilize C string literals" rust#117472 **Link:** https://github.com/rust-lang/rust/pull/117472 TC: This is a stabilization of RFC 3348: https://rust-lang.github.io/rfcs/3348-c-str-literal.html > # Stabilization report > > Stabilizes C string and raw C string literals (`c"..."` and `cr#"..."#`), which are expressions of type [`&CStr`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. > > ```rust > const HELLO: &core::ffi::CStr = c"Hello, world!"; > ``` > > C strings may contain any byte other than `NUL` (`b'\x00'`), and their in-memory representation is guaranteed to end with `NUL`. > > ## Implementation > > Originally implemented by PR #108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. > > The current implementation landed in PR #113476, which restricts C string literals to Rust edition >= 2021. > > ## Resolutions to open questions from the RFC > > * Adding C character literals (`c'.'`) of type `c_char` is not part of this feature. > > * Support for `c"..."` literals does not prevent `c'.'` literals from being added in the future. > > * C string literals should not be blocked on making `&CStr` a thin pointer. > > * It's possible to declare constant expressions of type `&'static CStr` in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of `CStr`. > > * The unstable `concat_bytes!` macro should not accept `c"..."` literals. > > * C strings have two equally valid `&[u8]` representations (with or without terminal `NUL`), so allowing them to be used in `concat_bytes!` would be ambiguous. > > * Adding a type to represent C strings containing valid UTF-8 is not part of this feature. > > * Support for a hypothetical `&Utf8CStr` may be explored in the future, should such a type be added to Rust. tmandry: It looks good. NM: +1. scottmcm: Let's do it. tmandry: I'll propose FCP merge. **Consensus**: Let's do this. ### "Exhaustiveness: reveal opaque types properly" rust#116821 **Link:** https://github.com/rust-lang/rust/pull/116821 TC: Oli nominated this one for us: > Nominating for T-lang discussion, as this allows more code to compile (both on stable, but especially on nightly around type-alias-impl-trait). TC: Nadrieril describes the change as: > Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the defining scope of an `impl Trait` opaque type, exhaustiveness uses the real type. From what I can tell, this doesn't change anything for non-empty types. > > I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCPs. > > The observable changes are: > > * when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.: > > ```rust > #[derive(Copy, Clone)] > enum Void {} > fn return_never_rpit(x: Void) -> impl Copy { > if false { > match return_never_rpit(x) {} > } > x > } > ``` > > * this properly fixes ICEs like [ICE: `Unexpected type for 'Single' constructor` #117100](https://github.com/rust-lang/rust/issues/117100) that occurred because a same match could have some patterns where the type is revealed and some where it is not. > > Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty. > > Fixes #117100 TC: CE confirmed to me that this approach is correct. scottmcm: Those bullets make sense to me. Should this be T-types as well. NM: Yes, I think so. tmandry: The change looks reasonable. NM: Should we defer this pending the meeting today? TC: It's probably orthogonal to the issue of today's meeting, and this one affects RPIT. TC: The description in the issue is a bit wrong as it pertains to TAIT. It say "within the defining scope", but it clearly means "within a defining item". scottmcm: We could FCP the RPIT part and ask for clarification on the TAIT parts. tmandry: +1. scottmcm: I'll FCP merge. *Consensus*: We'll propose FCP merge. ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 TC: This was previously blocked on concerns raised by lcnr about the completeness of the stabilization report. These have now been resolved, and nikomatsakis proposed that we nominate this issue for discussion. TC: When we last discussed this substantively, we seemed in favor of moving forward. What do we think now? TC: The stabilization report is here: https://hackmd.io/QggP6SJVTa2jb7DjGq0vrQ wffl: I was thinking about those questions: https://github.com/rust-lang/rust/issues/65991#issuecomment-1529933162 - [x] Exponential (?) blowup in size (raised @ https://github.com/rust-lang/rfcs/pull/3324#issuecomment-1305015681) - Conclusion: We put out a request for data in [#112355](https://github.com/rust-lang/rust/issues/112355). The data gathered did not suggest major impact (e.g., nbdd0121 found <0.2% overhead in the size of text sections). Furthermore, the vtables in practice have included upcast support for a long time and so this is not making anything *larger*. - [x] Whatever we are fine with making creating `*const dyn Tr` with invalid metadata invalid, to support safe coercions (resolved by https://github.com/rust-lang/rust/issues/101336#issuecomment-1250356226) - [x] Should we make upcasting opt-in in some form to limit vtable size by default? The current inclination of the lang-team is "no", but it would be useful to gather data on how much supporting upcasting contributors to overall binary size. - Answer: no. This would create complexity for all Rust users with very little practical benefit (size impact, as measured above, is very little). - [x] Should we add an opt-out mechanism, and extend library stabilization checklist with "do we want to opt-out for now"? - Answer: we are not adding a mechanism but we can do it later. We wouldn't be able to apply it to the standard library traits but we did an analysis (in the stabilization report) and found that we would not want that anyway. - [x] Whatever there are concerns with traits in the ecosystem outside of the standard library (raised @ https://github.com/rust-lang/rust/issues/65991#issuecomment-1369970129) - Answer: No, based on our data, we are not concetrned. - [x] While `trait A: B` is upcastable, should `trait A where Self: B` be? (raised @ https://github.com/rust-lang/rust/issues/65991#issuecomment-1294081137) - Answer: Yes, and it is, because all other places in Rust treat `trait A: B` as equivalent to `trait A where Self: B` ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=60b586c26727f642102cc1c867fee13e)). Some of those may have already been addressed/decided, but I could find where, if they even were. Anyway this is something the stabilization report / lang team will need to address. NM: Given the data we have, I think we can say that we're alright here. NM: Let's close: https://github.com/rust-lang/rust/issues/112355 NM: The issue has collected the data that wanted. I'll close it. NM: I'm answering the open questions above. We shouldn't add opt-in or opt-out. We're not concerned about traits in the ecosystem based on the data we have. wffl: FCP is here: https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127912 wffl: (answering to Tyler) `*const dyn A` -> `*const dyn B` is implicit and safe: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3f3b53c11c7796ee6a38c709555505aa NM: The resolution to the safety rules is "when a raw pointer escapes to safe code, it must have a valid vtable". This also implies that if we have `trait Foo { fn foo(*const self) }` and `x: *const dyn Foo`, we can permit `x.foo()` to be safe, which was an outstanding design question that was blocking `*const` methods. Let's move on those! *Consensus*: We're in FCP. ### "dyn Trait comparison should not include the vtable pointer" rust#106447 **Link:** https://github.com/rust-lang/rust/issues/106447 TC: Amanieu has a new proposal about what to do here: > > We did discuss about potentially deprecating `dyn Trait` pointer comparison during the meeting, but it's hard to so because we can't deprecate trait impl. > > I would like to propose the following plan: > > * Change the semantics of dyn trait pointer comparison to only look at the address. This is necessary to ensure that such pointer comparisons produce consistent results rather than depending on codegen unit splitting and how LLVM merges vtables. > * Deprecate comparisons (Eq/Ord) on dyn trait pointers by adding a lint which encourages people to cast the pointer to `*mut u8` first. This makes the intent of such comparisons much clearer. scottmcm: The first bullet looks the same as before. NM: We should just do the second one maybe. In general I can't rely on the false value, but I can rely on a true. But under this, I can't rely on either. scottmcm: 100% let's do the second bullet. We can push people toward the new function that's now on nightly. But I agree with NM that I'm still not in favor of the first bullet. It's a very subtle breaking change that's scary. scottmcm: If the proposed behavior was significantly better, maybe. But it's really not. scottmcm: Maybe we should create an issue for the lint and mark it help-wanted. I'll do that. NM: I'll leave a comment in the original issue. *Consensus*: We're in favor of a lint, but still not in favor of changing the behavior. But of course we don't like the current behavior. [Niko's comment summarizing meeting consensus.](https://github.com/rust-lang/rust/issues/106447#issuecomment-1802260025) waffle: If someone wants, they can add `Any` to their trait and compare that. NM: They can. But I'd rather that equals didn't do wrong things. scottmcm: The trait is the evil part. I don't know what to do about that. ### "patterns: reject raw pointers that are not just integers" rust#116930 **Link:** https://github.com/rust-lang/rust/pull/116930 TC: RalfJ nominated this for us: > @rust-lang/lang this PR does three things: > > * it fixes our old lint that detects match on function pointers and wide pointers to also catch cases where those pointers are hidden inside other types > * it makes that lint warn-by-default (but doesn't yet make it show up in dependencies) > * it makes the lint also trigger when encountering a raw pointer that was not constructed via `int as *const/mut T`, but e.g. via `&something as *const T` -- those allocations don't have guarantees on their ptr equality just like function pointers and vtables, so we should reject them for the same reason. > > We haven't reached a proper conclusion in the recent "match on const" meeting, but the general direction seems to have been towards "it should still work like a pattern" (and not like sugar for `==`), and this PR is a crucial step towards ensuring that they do indeed behave like a pattern, with structural properties and all that. Even if the goal is just to future-proof against both options (as has been the strategy so far), we want this warning. > > Crater found only 3 cases where the warning triggers, in the entire ecosystem. All of them would already warn on stable if they enabled the lint; the new cases covered by this PR were not detected at all by crater. TC: RalfJ said: > Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. waffle: Does RalfJ mean lint or hard error? waffle: Looking at the PR, it looks like just a lint for now. NM: I think it's fine, it's a good idea. NM: And I'm ready to close the match issue. We have to accept that match is not an extensible mechanism for now. tmandry: It seems fine. wffl: :+1: TC: Does this just need a meeting consensus or an FCP. NM: There are no one-way doors. Let's do it as a meeting consensus. *Consensus*: Let's do this. ### "[`RFC 3086`] Attempt to try to resolve blocking concerns " rust#117050 **Link:** https://github.com/rust-lang/rust/pull/117050 TC: c410-f3r is looking for feedback about whether the approach he has taken, described in the following link, is the desired approach for resolving the blocking concerns: https://github.com/rust-lang/rust/issues/83527#issuecomment-1744822345 TC: What do we think? NM: markbt who drove the RFC seems in favor of it. NM: This looks right to me. scottmcm: This is nightly only, right? NM: Confirmed. NM: We probably still want to FCP it as we're making a change to the semantics. NM: Of course, it's also not a one-way door. *Consensus*: We'll leave a note this sounds OK. We'll ask that this be mentioned in the stabilization report. ### "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](https://github.com/rust-lang/rust/issues/116336) and [#60570](https://github.com/rust-lang/rust/issues/60570). NM: I can't come up with a reason that type parameters should behavior differently than other type names. I'm looking at the diff. But for the most part this seems correct. NM: Should this be T-style? scottmcm: Should it be T-libs-api? tmandry: There seem to be reasonably things in the compiler affected by this. tmandry: Consider: XMLHttpRequest / XMLHTTPRequest / XmlHttpRequest. NM: What's the real decision here? It's it defining what exactly camel case means? And what is the current behavior exactly? tmandry: Part of me wants to say that is more prescriptive. Maybe this should be a clippy lint. NM: I'm not really inclined to make this change. It's just churn. waffle: This is only adding new lints. NM: We can just say the rules are what they are. Not point in kicking this hornet's nest. The first rule of lints is to do no harm. We kind of don't want to get into a war about whether you should capitalize all acronyms. NM: You definitely need some amount of flexibility here. scottmcm: Three would be super noisy. NM: I'm inclined to close. But if not, we'd need a crater run. scottmcm: Maybe we should ask for more motivation. NM: I'm fine with that. scottmcm: Then maybe we just close it next week. *Consensus*: We'll leave a comment asking for more motivation. And we'll unnominate pending that motivation being provided. ### "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](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/341522535)) (Current implementation in rustc) > 2. The expectation is fulfilled if removing the `#[expect]` attribute would cause the warning to be emitted. ([src](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/354082551)) > > @xFrednet created a [list of use cases](https://hackmd.io/@xFrednet/expect-attr-use-cases) to help with the discussion of these two models; they found both models work equally well, except for [use case 4](https://hackmd.io/@xFrednet/expect-attr-use-cases#Use-case-4-Suppress-lints-from-CI) which would only be possible with the first model. TC: ...and proposes that we adopt option 1. niko: [Check your boxes!!](https://github.com/rust-lang/rust/issues/115980#issuecomment-1726287008) (The meeting ended here.) ### "static mut: allow mutable reference to arbitrary types, not just slices and arrays" rust#117614 **Link:** https://github.com/rust-lang/rust/pull/117614 TC: RalfJ nominated this for us: > For historical reasons, we allow this: > > ```rust > static mut ARRAY: &'static mut [isize] = &mut [1]; > ``` > > However, we do not allow this: > > ```rust > static mut INT: &'static mut isize = &mut 1; > ``` > > I think that's terribly inconsistent. I don't care much for `static mut`, but we have to keep it around for backwards compatibility and so we have to keep supporting it properly in the compiler. In recent refactors of how we deal with mutability of data in `static` and `const`, I almost made a fatal mistake since I tested `static mut INT: &'static mut isize = &mut 1` and concluded that we don't allow such `'static` mutable references even inside `static mut`. After all, nobody would expect this to be allowed only for arrays and slices, right?!?? So for the sake of our own sanity, and of whoever else reverse engineers these rules in the future to understand what the Rust compiler accepts or does not accept, I propose that we accept this for all types, not just arrays and slices. ### "Remove ability to disable some target features" rust#116584 **Link:** https://github.com/rust-lang/rust/pull/116584 TC: RalfJ nominated this for us. > Given that stabilizing target features seems to be a t-lang thing, I am going to assume the same applies here. > > @rust-lang/lang, we'd like to remove the ability to disable certain target features. The broad goal we are going for here is that **code built for the same target is ABI-compatible no matter the target features**. This is an easy rule to remember and a principle that it seems reasonable to enforce. This principle is currently violated in several ways (for x86, that's tracked in #116344 and #116558). This PR is one part of achieving that, [this pre-RFC](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Pre-RFC.20discussion.3A.20Forbidding.20SIMD.20types.20w.2Fo.20features) is another part, and then one final piece is needed to reject `+x87`/`+sse` on `x86_64-unknown-none` (or to reject float-taking/float-returning-functions) as that would similarly change the ABI. > > This particular PR fixes #116344 for our tier 1 targets. The issue is that disabling the "x87" feature on an x86 (32bit or 64bit) target changes the ABI, so linking two object files that were compiled with different target features can lead to UB in entirely safe code. In particular, calling any `float`-returning function from the standard library when `x87` is disabled will break (caller and callee disagree about where the return value should go), and if we want to fix #115567 by returning floats in SSE registers for "Rust" functions, then similar ABI incompatibilities will arise when `sse` is disabled. > > Disabling these target features also does not guarantee code that does not use SSE/x87 registers, since the standard library was built with those registers available. SSE registers are used even in code that doesn't involve any floats. So if the goal is to e.g. not save SSE registers in a context switch, then disabling the SSE target feature does not suffice, you also need to rebuild the standard library. > > In other words, `-sse`/`-x87` is (a) unsuited to generate code that doesn't use SSE/x87 registers, and (b) a major footgun due to ABI incompatibilities. We have the `x86_64-unknown-none` target for cases like that, which guarantees that all code, including the standard library, is built without use of SSE/x87 registers. (Many other architectures have similar softfloat targets. This PR here is for x86 only, but we should do a thorough audit of all stabilized target features and keep this concern in mind when stabilizing target features in the future.) ### "References refer to allocated objects" rust#116677 **Link:** https://github.com/rust-lang/rust/pull/116677 TC: RalfJ nominated this for us: > Yeah, that sounds good to me. This is technically a t-lang decision (validity invariants are t-opsem but safety invariants are not), so let's nominate for their discussion. ### "Document that <- is a single token" reference#1424 **Link:** https://github.com/rust-lang/reference/pull/1424 TC: ehuss nominated this for us: > Since there was an attempt to remove this that was then later backed out, I'm assuming the language team agrees that the emplacement operator has to stay permanently. However, I'm not 100% sure based on [rust-lang/rust#50832 (comment)](https://github.com/rust-lang/rust/issues/50832#issuecomment-389884751). > > Since I'm not completely confident that the language team doesn't want to try to remove this in the future, I'm going to nominate this for their attention for approval. I think this PR probably should be merged. I wouldn't be surprised if there were more macros using it since the last time it was attempted to be removed. ### "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. ### "`.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 by WG-async. @tmandry said: > We discussed this in a recent wg-async meeting ([notes](https://hackmd.io/G6ULofyXSIS4CK9u-jwYRg)). 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. ### "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](https://doc.rust-lang.org/rustc/lints/levels.html) 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. ### "Uplift `clippy::precedence` lint" rust#117161 **Link:** https://github.com/rust-lang/rust/pull/117161 TC: The proposal is to lint against: ```rust -2.pow(2); // Equals -4. 1 << 2 + 3; // Equals 32. ``` These would instead be written: ```rust -(2.pow(2)); // Equals -4. 1 << (2 + 3); // Equals 32. ``` Prompts for discussion: - Is this an appropriate lint for `rustc`? - How do other languages handle precedence here? - Is minus special enough to treat differently than other unary operators? ### "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](https://github.com/rust-lang/rust/pull/106418#issuecomment-1736377423) 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](https://doc.rust-lang.org/nightly/std/mem/fn.discriminant.html#stability). 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. TC: Do we have any further thoughts here? ### "RFC: Syntax for embedding cargo-script manifests" rfcs#3503 **Link:** https://github.com/rust-lang/rfcs/pull/3503 TC: We discussed this extensively in the [2023-11-01 meeting](https://hackmd.io/ZTUXE9EES9eNDX1GaLpoQw). We did not come to any consensus other than that we were open to frontmatter in some form. ## Action item review - [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## Pending lang team project proposals None. ## PRs on the lang-team repo ### "Update Auto Traits Freeze Discussion Link" lang-team#231 **Link:** https://github.com/rust-lang/lang-team/pull/231 ## 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 ### "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 ### "warn less about non-exhaustive in ffi" rust#116863 **Link:** https://github.com/rust-lang/rust/pull/116863 ## 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 ### "MaybeDangling" rfcs#3336 **Link:** https://github.com/rust-lang/rfcs/pull/3336 ### "add float semantics RFC" rfcs#3514 **Link:** https://github.com/rust-lang/rfcs/pull/3514 ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 ### "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 ### "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 ### "Decision: semantics of the `#[expect]` attribute" rust#115980 **Link:** https://github.com/rust-lang/rust/issues/115980 ### "Stabilize Wasm target features that are in phase 4 and 5" rust#117457 **Link:** https://github.com/rust-lang/rust/pull/117457 ### "Stabilize Wasm relaxed SIMD" rust#117468 **Link:** https://github.com/rust-lang/rust/pull/117468 ## Active FCPs ### "TAIT defining scope options" rust#107645 **Link:** https://github.com/rust-lang/rust/issues/107645 ## P-critical issues None.