---
title: Triage meeting 2023-11-01
tags: T-lang, triage-meeting, minutes
date: 2023-11-01
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202023-11-01
url: https://hackmd.io/ZTUXE9EES9eNDX1GaLpoQw
---

# T-lang meeting agenda

- Meeting date: 2023-11-01

## Attendance

- People: TC, Urgau, waffle, pnkfelix, Josh, eholk, nikomatsakis, scottmcm, tmandry

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-11-01: Planning meeting

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

### Plan for 2024 edition

JT: I may not make the planning meeting, but we should be sure to plan for the 2024 edition.

## Nominated RFCs, PRs, and issues

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

[dependencies]
clap = { version = "4.2", features = ["derive"] }

use clap::Parser;

TC: tmandry commented:

> With my lang hat on, I don't see a reason we should RFC a feature that only allows `cargo` front matter, without specifying a path to generalizing it to other tooling. If we want to be conservative in what we stabilize, let's approach that in the stabilization rather than in the RFC.
>
> At the language level we should acknowledge that not all projects get to use cargo, and the generalization here seems trivial to do in the RFC. Note that I'm fine with the RFC being conservative in other ways (only allowing one, right after the shebang, etc).
>
> Taking off my lang hat now – using `cargo` sure makes it awkward to extend to embedding a second front matter with Cargo.lock. It'd be nice if the RFC addressed that. (Maybe just say "we can use `cargo-lock` for consistency with `cargo`"?)

TC: +1 from me there.

TC: To perhaps prompt discussion, here are some thoughts I earlier wrote down when reviewing this RFC:

- The code string literals RFC had also proposed to use Markdown code block syntax. In the discussion surrounding that, the feeling was that may be a bridge too far. Would we feel differently here?

- Even if cargo never wanted to support `Cargo.lock` or other files, it's clear that other build tools may want to support these. Go's similar feature, `gorun`, has this same problem and therefore spells out the name of each file in the syntax. Are we sure we don't want to do that?

- The key T-lang concern here is specifying "what's allowed in a .rs file?" This has wider ecosystem implications on editors, syntax highlighters, rust-analyzer, etc. To what degree are we willing to break existing such tools with new syntax? And to what degree does this influence whether we should adopt a more general solution than just what works for Cargo's planned feature?

- Perhaps we should consider a new kind of comment for frontmatter in Rust 2024 that preserves the symmetry with existing comment types? E.g. we could use `//+` and `/*+ */`. This would have the advantage of not breaking existing parsers as it would be a legal comment in the old edition.

- There's overlap between this and the code string literals RFC. Both want to embed some structured non-Rust file in a Rust file. Both are hoping for eventual support from editors and other tools. Is there perhaps a way to build one on the other? E.g., perhaps we could add a `set_build_file!("Cargo.toml", ..)` macro where the second argument is expected (by convention) to be spelled with a code string literal. We could lint or error on "complicated" uses of that macro that may not be understood by tools.

- Some of the examples in the RFC don't specify the edition. The related RFC 3502 suggests these would be interpreted as refering to whatever the current edition is, and that breakage on `rustc` upgrades may be expected. Is this acceptable to T-lang?

TC: What thoughts do people have about this?

JT: Regarding the edition, the proposal is that any program that *doesn't* specify an edition will emit a warning, but still run. That way, people can successfully run the program, but will have a warning they need to fix (ideally with a `cargo fix` you can apply).

NM: Is it up to the tool to interpret the identifier?

tmandry: That's the idea, I think.

Josh: We've talked about similarly general mechanism. And we said we didn't want passthrough for arbitrary tools into Rust. The syntax is extensible. But do we want to safe-list specific tools?

pnkfelix: Or we could allow anything after a she-bang and leave it up to the tool for what it means. Racket does it this way. E.g.:

https://docs.racket-lang.org/guide/scripts.html

pnkfelix: (I want to draw attention to the last line in section 21.2.1 of above link: "Note that #! starts a line comment in Racket, and #|...|# forms a block comment.")

pnkfelix: ...or at least a namespaced form

pnkfelix: ...e.g. something like ```rustdoc::css

pnkfelix: ...(which would then imply that this RFC should instead say triple-backtick + cargo::toml.

scottmcm: Is there just one of these? Is it always ignored by rustc? Maybe the difference is that Rust is ignoring this.

tmandry: There are two possible interpretations. One is that Rust ignores the text completely. The other is that it desugars to some mod-level attribute.

Josh: I don't know what future tools might want. But I'd imagine tools will not be parsing Rust macros. Nothing in Rust will be run before this is parsed.

NM: I don't recall a consensus on not wanting passthrough. Do you have context?

Josh: It was some manner of tool attributes mechanism. Maybe it was something about proof tools that want to support Rust.

NM: This seems different than that scenario to me. It'd be helpful to drill into any concerns about it being more extensible. I think of this as some way to give more information that's used by the tool on the shebang line. It could be an error to have these things without a shebang line. I'm not sure what the forwards-compatibility concern is.

Josh: This seems like a case where what people do will affect what we can do in the future. What if there are multiple tools?

NM/tmandry: There can only be one tool with shebang.

pnkfelix: ...

Josh: We already ignore the shebang. This is about the bit after the shebang.

NM: The concern is about something else using the syntax and then passing through to cargo...? But they already would have received an error?

Josh: That's the question. Who is responsible for checking for errors? I'm suggesting it's the language's responsibility to detect the error.

NM: My assumption is that this is a comment to Rustc. We can choose how strict we are about things on the shebang. But it'd make more sense for rustc to be liberal. I don't see the forwards-compat concern in this scenario.

pnkfelix: What is the treatment of the syntax?

Josh: rustc ignores it.

scottmcm: I'm unclear about why `rustc` would care about this. IF we have the rule that whatever is in this block is the responsibility of the shebang processor and rustc ignores it.... I don't know how to justify being strict.

Josh: I'd expect this is more generally a place to put metadata for tools that don't use Rust syntax, not just for a shebang. E.g. you could embed a rustfmt toml. You could put directives for any tool in the pipeline. In that context, user tools could conflict with the namespace.

scottmcm: This goes back to why we might want the attribute form again. Maybe we want tool attributes, because a namespace becomes important again.

Josh: I'd expect we could extend this to a block that could be anywhere.

scottmc: "Anywhere" scares me -- I don't want this in:

foo::<

...

4>()

...like other things can be.

pnkfelix: scottmcm: Maybe better to restrict these to appearing as a consecutive sequence at the start of the `.rs` file, before any noncomment input (including no `#![attributes]`).

TC: There may be some overlap here with other proposals, such as for code string literals. Both want to add a way to embed non-Rust syntax in a Rust file with the hope that editors and other tools will recognize them. We could imagine using that along with a simple macro, and linting against "complex" uses of the macro, such as behind `cfg` or not at the top level.

NM: I could also imagine crate-level attributes.

Josh: Are we aligned on having a triple-backquoted block? And we just have questions on details.

TC: Isn't the syntax itself a detail?

Josh: The ask is to reduce complexity.

pnkfelix: I'm surprised that `/* ... */` is unintuitive. (I can grant that it is perhaps ugly.)

pnkfelix: (I know you said "doc comment i.e. `///` which is not the same)

Niko Matsakis: My take: I am happy to accept triple-backtick strings that we ignore as front matter (perhaps only when a `#!` is present). I don't like this as a general mechanism.

Josh Triplett: Cargo folks were disinclined towards any non-doc comment being "active", and I'd have the same objection.

Josh Triplett: Assuming it's a doc comment, the unintuitive part was the full combo of:

//! ```cargo 

Niko Matsakis: I think thatspecifying "extra annotations" that side tools can use can be done with `#![rustfmt configuration="..."]`

scottmcm:

/**```cargo
stuff here

scottmcm: Isn't *that* horrible, IMHO, since I'd be copy-pasting it anyway for a cargo toml, I think.  But people hate `/**` comments, for some reason.

scottmcm: But I agree that adding something special-cased for it is a reasonable thing to do. 

Urgau: Would it be possible to simply extend rustc unaware of `#` all the first lines instead of just the first one?

pnkfelix: (I don't mind adding syntactic support for this in some form. I just want to ensure we're all aligned about it, which is why I wanted to raise it explicitly.) 

Josh Triplett: pnkfelix: +1 

Urgau:

#!/usr/bin/cargo
# [package]
# ...
# [dependencies]
# ...

?

Josh Triplett: @Urgau: No objection, but there's no obvious way to ever allow lockfiles that way. 

Josh: If it's in an attribute, things may expect to be able to deal with this in the AST in ways that don't make sense.

NM: I feel like we're misaligned on the purpose of the feature.  In my head, we're extending shebang.  Josh seems to have a more general purpose.  That feels like more than syntax.

scottmcm: The intent question feels like where we have questions.  Are we associating this with the shebang, or is it more general. The syntax depends on how we're thinking of this.

pnkfelix: The way this does interact with syntax in a deep way.  Do the people who want this think it's OK if this is just a comment to Rust.  Then you can sidestep a lot of this.  Is that answer unpalatable to these groups?

Josh: That syntax was discussed extensively by cargo.  There was a lot of effort to find things that would be parsed and ignored.

TC: This hasn't been discussed with T-lang though.

tmandry: The doc-comment syntax did feel heavy.  I also see it more as something for shebangs and tools more generally.

Josh: Are we in favor of having frontmatter generally?

NM: Seems no-one opposed that.

*Consensus*: We seem to be open to some manner of frontmatter.  But we're lacking consensus further than that.  Let's maybe open a meeting request for this.

### "Stabilize Wasm target features that are in phase 4 and 5" rust#117457

**Link:** https://github.com/rust-lang/rust/pull/117457

TC: PR proposes:

> This stabilizes the Wasm target features that are known to be working and in [phase 4 and 5](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180).
>
> Feature stabilized:
>
> * [Non-trapping float-to-int conversions](https://github.com/WebAssembly/nontrapping-float-to-int-conversions)
> * [Import/Export of Mutable Globals](https://github.com/WebAssembly/mutable-global)
> * [Sign-extension operators](https://github.com/WebAssembly/sign-extension-ops)
> * [Bulk memory operations](https://github.com/WebAssembly/bulk-memory-operations)
> * [Extended Constant Expressions](https://github.com/WebAssembly/extended-const)
>
> Features not stabilized:
>
> * [Multi-value](https://github.com/WebAssembly/multi-value): requires rebuilding `std` [Multi value Wasm compilation #73755](https://github.com/rust-lang/rust/issues/73755).
> * [Reference Types](https://github.com/WebAssembly/reference-types): no point stabilizing without [Support for WebAssembly externref in non-web environment #103516](https://github.com/rust-lang/rust/issues/103516).
> * [Threads](https://github.com/webassembly/threads): requires rebuilding `std` [Tracking issue for WebAssembly atomics #77839](https://github.com/rust-lang/rust/issues/77839).
> * [Relaxed SIMD](https://github.com/WebAssembly/relaxed-simd): separate PR [Stabilize Wasm relaxed SIMD #117468](https://github.com/rust-lang/rust/pull/117468).
>
> See [#117457 (comment)](https://github.com/rust-lang/rust/pull/117457#issuecomment-1787648070) for more context.
>
> Documentation: [rust-lang/reference#1420](https://github.com/rust-lang/reference/pull/1420) Tracking issue: #44839

TC: alexcrichton helpfully filled in some background:

> AFAIK a stabilization policy is not documented anywhere for WebAssembly target features, but in my opinion this is a good PR to land.
>
> As a bit of background on this in case anyone's curious: WebAssembly target features in LLVM relate to [WebAssembly proposals](https://github.com/WebAssembly/proposals/) and are frequently named after those proposals. WebAssembly proposals go through a phased design process similar to JS and once a feature reaches "phase 4" it's effectively done and ready for everyone to use. That's when browsers start shipping the feature ungated for example. There is no "standard" for what to call these proposals beyond "toolchain conventions" which, at this time, is "whatever LLVM called it". In that sense the choice of feature name here matches what one would use on the command line for C/C++ when compiling WebAssembly.
>
> This particular proposal, along with others, as pointed out, is "stage 5" which means it's long since done and overdue for stabilization on our end.

NM: I think we should do this.

JT: +1

NM: I'll propose FCP merge.

scottmcm: https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md

pnkfelix: https://docs.google.com/presentation/d/1sM9mJJ6iM7D8324ipYxot91hSKnWCtB8jX4Kh3bde5E/edit?pli=1#slide=id.gc6fa3c898_0_0

...

NM: I think it's passing flags through to LLVM to allow use of these features.

JT: This is not a Rust syntax change.  You'll allowed to generate wasm file that has these instructions in these areas.

pnkfelix: I'm curious, do you have to use inline wasm to make use of this?

JT: I would expect LLVM's codegen to leverage this.  You'd pass `target-feature` or similar.

NM: Is this compiler + lang?

scottmcm: We have said these are lang as well in the past.  Both would make some kind of sense.

### "RFC: Packages as (optional) namespaces" rfcs#3243

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

TC: epage nominated this for us:

> I marked this as I-lang-nominated to double check with the lang team that they are ok with the semi-open namespaces concept being added to the language as suggested in the Cargo team meeting.

JT: The namespace proposal intersects with lang in the sense that if you have a namespaced package `a::b` we have to allow that to be injected and deal with the name collisions.  IF we have a concern about that, we should raise that.

scottmcm: You can do that with `extern crate` within a module?

JT: But you can't do that with someone else's crate.  You could have a crate `a` and a crate `a::b`.

TC: Should we have a different syntax for it?

scottmcm: Finding one that would work in every path sounds horrible.

pnkfelix: What reasons would we have for using a different syntax?

TC: It's just raised for discussion how much we care about the ambiguity.

NM: It's probably fine.  Cargo will probably tell us the set of organizations coming in from the `Cargo.toml`.

NM: What did we use for tool attribute macros?

JT: It was two colons.  We don't have anything that uses one.

scottmcm: We could always think of this as desugaring to module imports.

JT: Someone asked us for an inline crate syntax.  If we had such a syntax, it would be trivial to write such a desugaring here.

NM: My expectation is you'd only resolve the ambiguity on the first token in the path.

pnkfelix: I can imagine adding a disambiguation mechansim like `a::crate b`.

pnkfelix: ...(or `a::<crate b>` perhaps).

scottmcm: I think we could think of this as something like

mod __ignore { pub extern crate a; pub extern crate b; }
mod a {
pub use super::__ignore::b;
pub used super::__ignore:🅰️😗;
}

which I'm pretty sure we already handle, so I don't think I have an objection.

JT: @pnkfelix: I'd sooner say "if you have both a namespaced package a::b and a symbol `b` in `a`, you get a conflict.

pnkfelix: Josh: My motivation is to support an alternative (expanded) syntax that is inherently unambiguous. 

pnkfelix: pnkfelix says:Josh: I would also want some kind of diagnostic when an ambiguity *does* arise. 

Josh: @pnkfelix: Fair enough. No fundamental objection to adding *some* kind of unambiguous syntax, though I'd expect devising that syntax to be a fun bikeshed. 

Josh: @pnkfelix: bikeshed paint color: `a::crate::b` (with a subsequent double-colon, rather than a space). 

pnkfelix: (As opposed to the subtlety of ambiguity errors/resolution.)

pnkfelix: (But I know it's not the same to make everyone pay for `:::` in order to defend against the hopefully rare case of ambiguities.)

Josh: pnkfelix: In addition to that cost, there's also the conceptual distance: `::` means "namespace" in Rust, so using it again to mean "namespace" reuses a concept in a way people will hopefully understand. 

NM: The basic decision we're making is whether to use `::` or some other thing, such as `:::`, `:`, or `/`.

JT: The objection was subtlety.

scottmcm: But here it wouldn't compile.

scottmcm: I'll post a comment that lang doesn't want to block this.

JT: Do we need an FCP for this?

all: It's a meeting consensus.  We're all here.

*Consensus*: Let's do this.  But let's think extra carefully about SemVer collisions on these crates before stabilization, but it doesn't need to block the RFC.

(The meeting ended here.)

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

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

### "[`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?

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

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

### "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 (and for T-types) 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:

-2.pow(2); // Equals -4.
1 << 2 + 3; // Equals 32.

These would instead be written:

-(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?

### "Stabilize C string literals" rust#117472

**Link:** https://github.com/rust-lang/rust/pull/117472

TC: This needs a stabilization report.  It's probably worth waiting on that to discuss.

### "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: Let's give some more time for context to develop on the thread before discussing in the meeting.

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

## Active FCPs

### "Lifetime Capture Rules 2024" rfcs#3498

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

### "TAIT defining scope options" rust#107645

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

### "Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`" rust#116218

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

### "Guarantee that `char` has the same size and alignment as `u32`" rust#116894

**Link:** https://github.com/rust-lang/rust/pull/116894

### "document that the null pointer has the 0 address" rust#116988

**Link:** https://github.com/rust-lang/rust/pull/116988

### "Guarantee that raw pointer conversions preserve slice element count" reference#1417

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

## P-critical issues

None.