T-lang meeting agenda

• Meeting date: 2023-11-15

Attendance

• People: TC, tmandry, scottmcm, JT, waffle, eholk

Meeting roles

• Minutes, driver: TC

Scheduled meetings

• 2023-11-15: "2024 Edition Review" #234
• 2023-11-29: "weak alias types for Rust 2024" #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

"Disallow future-incompatibility lints in the next edition" rust#117921

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

TC: We'll be discussing more general 2024 edition issues later today, but this issue seems it should be discussed separately with priority. tmandry gives the context:

We have quite a long list of future-incompatibility lints that are waiting to be made into hard errors. The lints are so severe that we warn even when they are used by a dependency of the crate being built, because they will cause the crate to stop compiling at some point in the future.

We could use the edition as an impetus to switch some or all of these lints over to hard errors (or deny-by-default lints). Note that because of the way editions work this would only affect the crate being upgraded, not its dependencies. This would mean pairing the carrot with the stick, so to speak; if any of the crates triggering these errors are upgraded to the edition they will also need to have their future-incompat issues fixed. It also means that new code (using the latest edition) won't be written that triggers these lints.

On the other hand it's unlikely that the crates with future-incompat issues are being maintained in the first place, so this wouldn't do much to help the problem.

Opening this issue for discussion and consideration by the lang team.

For some background on past editions, see #80165 (comment).

TC: There are 39 of these issues open, though not all are plausible candidates. Let's maybe take a few of these per meeting.

tmandry: I don't see any reason to make these at least deny-by-default lints. We could even make them hard errors and it wouldn't impact your downstream crates. So I don't see a reason to not do this.

waffle: Can we make it an automatic rule to always make future-incompat lints into hard errors in the next edition?

tmandry: Probably, in general.

JT: I don't see a reason to not do this either.

TC: Do we want to do these all by meeting consensus or by FCP?

tmandry: I was leaning toward FCP.

JT: Probably that.

TC: Should we FCP each of these or FCP a policy decision?

JT: I'm not sure whether we were clear in the past when making things future-incompat lints about what we intended.

scottmcm: We've discussed in the past this isn't exactly clear. The future-incompat lint actually means that we might break this without an edition at all. And of course, the compiler still has to support it in older editions.

JT: It does mean that a feature in a new edition doesn't need to consider the disallowed thing.

scottmcm: But we try to not add features only to new editions.

scottmcm: I really doubt that lang has made a strong decision for each of these lints.

JT: If we wanted to FCP a policy that all future-incompat lints are meant to be hard errors in future/all editions, we could do that for all such lints going forward.

JT: I'd also be OK with FCPing together making all the lints into errors in a future edition, but not for the current edition.

scottmcm: That would raise the bar on adding these lints, since we'd be committing to not change our mind.

Consensus: Let's maybe write up an RFC for a new policy. And let's have someone propose which should be errors in every edition and which should be errors in the next edition.

Tracking Issue for BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE lint - #107457

Link; https://github.com/rust-lang/rust/issues/107457

TC: nnethercote gives the context:

The lint detects cases where derive is used with a packed struct that contains a [u8] field.

This lint will trigger for code like this:

#[repr(packed)]
#[derive(Eq, PartialEq)]
pub struct FlexZeroSlice {
    width: u8,
    data: [u8], // triggered
}

At some point in the future this case will be disallowed.

See #104429 for more details, especially the t-lang nomination.

Consensus: Given the outcome above, we'll defer discussion of this.

Multiple incompatible clashing extern fn's should be a hard error (potentially phased in via future-incompat) - #105146

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

TC: @pnkfelix gives the context:

I tried this code (playpen):

pub mod a {
    use std::ffi::c_int;
    extern "C" { fn isalpha(_: c_int) -> c_int; }
    pub fn wrap(x: c_int) -> c_int { unsafe { isalpha(x) } }
}

pub mod b {
    use std::ffi::c_int;
    extern "C" { fn isalpha(_: c_int, _: c_int) -> c_int; }
    pub fn wrap(x: c_int, y: c_int) -> c_int { unsafe { isalpha(x, y) } }
}

fn main() {
    dbg!(a::wrap(10));
    dbg!(b::wrap(10, 20));
}

I expected to see this happen: code should be rejected as obviously wrong, since within the same codegen unit, it is using two incompatible declarations for the same external foreign function.

…

I personally suspect that this error represents enough of a red flag that we really should be aiming to turn the existing lint into a hard-error, even if only over an edition boundary for the language.

Consensus: Given the outcome above, we'll defer discussion of this.

Tracking Issue for deprecated_cfg_attr_crate_type_name lint - #91632

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

TC: @bjorn3 gives the context:

The deprecated_cfg_attr_crate_type_name lint detects uses of the #![cfg_attr(..., crate_type = "...")] and #![cfg_attr(..., crate_name = "...")] attributes to conditionally specify the crate type and name in the source code. For example:

#![cfg_attr(debug_assertions, crate_type = "lib")]

The #![crate_type] and #![crate_name] attributes require a hack in the compiler to be able to change the used crate type and crate name after macros have been expanded. Neither attribute works in combination with Cargo as it explicitly passes --crate-type and --crate-name on the commandline. These values must match the value used in the source code to prevent an error.

TC This is already deny-by-default. The next step is to make this a hard error.

Consensus: Given the outcome above, we'll defer discussion of this.

"MaybeDangling" rfcs#3336

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

TC: This was proposed for FCP merge three weeks ago. tmandry proposed this could go forward ahead of acceptance of the RFC using the process for experiments. RalfJ is certainly an "experienced Rust contributor". We would also need a liaison from this group. Any volunteers?

JT: No objection to him going forward as an experiment.

tmandry: I'll liaison it. I'll comment on the RFC.

scottmcm: It will need tracking issue anyway.

JT: We can ask RalfJ to create that.

Consensus: tmandry will second, and this can move forward as an experiment.

---

TC: Separately, tmandry said:

I share a concern about the proliferation of value type wrappers, and am pretty interested in exploring attributes.

Does this merit discussion, in terms either of moving the RFC forward, or suggesting a path from this group that the experiment might explore?

scottmcm: My inclination is to accept it as-is. We'd probably want the type anyway. If there's a way to apply the type in a place that attributes don't work well, that's not a bad thing.

tmandry: There will be an attribute hiding behind it anyway that could be used for experimentation.

scottmcm: Here's what I mean about where attributes aren't a good fit.

fn foo(x: MaybeDangling<Box<Blah>>)

I don't think we'd allow

fn foo(#[maybe_dangle] x: Box<Blah>)

TC: Right, the attribute proposal isn't to allow that, but that people would use it to define types or wrapper types that would go there.

scottmcm: If it's plausible we'd want a canonical type anyway for those use cases, we might as well have it in core.

TC/tmandry: +1.

Consensus: We'll move forward as an experiment.

Camel case and shouting case - rust#60570 / rust#116389

"type parameters expect camel case, but shouting case is also common" rust#60570

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

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

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

TC: These issues are two sides of the same coin. In the first, a plausible use case has been put forward for when shouting-case in type parameters may be reasonable. In the second, the author hopes to lint on upper-case words without underscores, but that would exacerbate the first issue and would additionally raise concern about some acronyms.

TC: In the 2023-11-08 meeting, we were concerned about churn and uncertain about the motivation of the latter issue. We nearly closed it, but instead decided to ask the author to address that. The answer is:

@sjwang05:

Can you say more about the motivation here? How essential is this?

I'd say the main motivation here (as mentioned in the original issue) is just to be more compliant with RFC430, though I wouldn't say it's essential, especially for 3-letter screaming words.

Personally, the note from #116389 (comment) about maybe moving the threshold for complaining about it seems potentially interesting as a way to have this handle the most egregious cases without being so noisy.

I agree–I think raising the limit to 4 upper-case characters would be a good compromise, though I'll leave the final call on what to do up to you all.

What do we think?

JT: I think part of the distinction here is that, since we're not semantically parsing English, we have no convenient way to tell the difference between an abbreviation, an acronym, an upper case word, etc. So it seems like we're enforcing style in such a way that people would see conceptually inconsistent results.

JT: Rather than making this more aggressive, we should make this less aggressive.

TC: Sounds like we should close second issue and comment on the first issue that we agree with the analysis.

JT: +1.

tmandry: I think agree with the outcome. I'm not in favor of enforcing this in rustc.

scottmcm: rb"foo" being an RBString and not getting linted seems entirely fine.

Consensus: Let's FCP close the second issue and leave a comment on the first.

"Exhaustiveness: reveal opaque types properly" rust#116821

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

TC: The change here applies to both RPIT and to TAIT, but the proposed wording for TAIT was a bit wrong. We decided in the 2023-11-08 meeting to not block the RPIT piece and proposed FCP merge (including T-types).

TC: The more general wording has now been fixed and needs review from T-lang. The question is, should this be the rule for Rust?:

Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.

TC: This is important for the new trait solver.

tmandry: That seems reasonable to me.

scottmcm: +1, I'm in favor of that wording.

Consensus: We'll leave a comment this wording is part of this FCP.

"Prevent opaque types being instantiated twice with different regions within the same function" rust#116935

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

TC: The question here is whether to adopt the following rule for Rust:

Within a single item, when multiple defining uses of an opaque type differ only by lifetime arguments, we must be able to prove that those lifetime arguments are equal, otherwise the code will be rejected, and once the new trait solver is stabilized, it will likely not be possible to lift this restriction in a fully backward compatible way.

TC: We discussed this at the 2023-11-08 design meeting on TAIT ("once modulo regions"), but it applies equally RPIT. E.g.:

pub trait Trait<'x> {}
impl<'x, T> Trait<'x> for T {}

pub fn test<'a, 'b>(a: &'a (), b: &'b ()) -> impl Trait<'a> {
    // ~^ ERROR lifetime may not live long enough
    // ~| NOTE argument requires that `'b` must outlive `'a`
    if false {
        let _ = test(b, b);
    }
    a
}

(This code is currently accepted.)

TC: This is about compatibility with the new trait solver which relies on invariants about Rust that make the above code impossible to accept.

TC: There was a crater run performed and no breakage was found.

scottmcm: Being able to separate type checking and borrow checking separately is an extremely strong motivation to me. +1.

tmandry: I am a bit worried about code that's not in crater. I'm inclined to accept this either way.

Consensus: Let's propose FCP merge.

"Add warn-by-default lint against unclear fat pointer comparisons" rust#117758

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

TC: To resolve #106447 ("dyn Trait comparison should not include the vtable pointer"), we decided to add a lint. This is that lint. But there may be an open question, and scottmcm nominated with:

Hmm, I think my personal vision of this was something like unclear_fat_pointer_comparisons that would lint on *const T for any T: ?Sized too, even without knowing what specific kind of DST it was. My thought was that even if you did intend to compare both (say because it's a slice and that's what you meant), it might still be good to use ptr::eq to help emphasize that you're not accidentally comparing the length too (like say if you forgot it was a slice pointer and not an item pointer).

But I'm not sure if that's what other people from the triage meeting were thinking. cc @Amanieu @rust-lang/lang @rust-lang/lang-advisors so others can chime in if they were thinking that this would check dyn only.

(Do people frequently compare slice pointers as a way of checking the length too? I don't know that I've ever seen code doing that, vs working in https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.len + data pointer separately…)

scottmcm: Please everyone have a look at this, since we asked people to write this lint.

scottmcm: One view of this is that dyn Trait ptr comparisons are unreliable and should be linted against. The other is that for fat pointer comparisons you should use the lib functions. I propose the latter. The former feels like a clippy lint.

JT: There is an argument for the second one being a kind of future-incompat lint.

scottmcm: I'm in agreement with that, so I must have been unclear earlier. The version that is "you are comparing vtable pointers using ==" is distinct from "doing vtable pointer comparisons are weird so you shouldn't do it."

scottmcm: One of the specific problems is what to name the lint, and our motivation matters for that.

scottmcm: Proposal: let's call this unclear_fat_pointer_comparison, and then we suggest to either compare the slice, cast the pointers to thin pointers (or addr_eq), or use the ptr::eq that is documented to compare both.

https://doc.rust-lang.org/nightly/std/ptr/fn.addr_eq.html

JT: We could stabilize these at the same time.

JT: I'll FCP the issue for addr_eq (with my T-libs-api hat on).

JT: Can we just FCP this lint and have it make these recommendations?

scottmcm: I'll write up an FCP proposal.

Consensus: We want to do something along the lines of what scottmcm has proposed, and he'll write up a specific proposal for FCP merge.

(The meeting ended here.)

"References refer to allocated objects" rust#116677

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

TC: To the page about reference, the proposal is to add this language:

Safety

For all types, T: ?Sized, and for all t: &T or t: &mut T, unsafe code may assume that the following properties hold. Rust programmers must assume that, unless explicitly stated otherwise, any Rust code they did not author themselves may rely on these properties, and that violating them may cause that code to exhibit undefined behavior.

• t is aligned to align_of_val(t)
• t is dereferenceable for size_of_val(t) many bytes

If t points at address a, being "dereferenceable" for N bytes means that the memory range [a, a + N) is all contained within a single allocated object.

"TAIT decision on "may define may guide inference"" rust#117865

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

TC: The question is whether this should be true:

The compiler is allowed to rely on whether or not an item is allowed to define the hidden type of an opaque type to guide inference.

Here's the door that this would close:

If this rule is adopted, then after TAIT is stabilized, it will not be possible in a fully backward compatible way to later change the rules that determine whether or not an item is allowed to define the hidden type in such a way that an item in existing code that uses an opaque type could switch (without any code changes) from being not allowed to define its hidden type to being allowed to define it.

TC: However, this basically boils down to whether we want both TAIT and the new trait solver, given the direction the new trait solver has gone. If we do want both, there's probably not a realistic alternative to this rule.

TC: Here's the short version. When we're type checking a body and we find an opaque type, we sometimes have to decide, should we infer this in such a way that this body would define the hidden type, or should we treat the type as opaque (other than auto trait leakage) and infer based on that? We can get different answers, so we need to know upfront.

TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque.)

"Properly reject default on free const items" rust#117818

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

TC: fmease explains:

The following code compiles successfully while it should lead to an error due to the presence of the contextual keyword default on the free constant item:

default const K: () = ();
fn main() {}

The AST validation code was incorrectly implemented and only rejects default on free const items that don't have a body:

default const K: ();

Technically speaking, this is a breaking change but I doubt it will lead to any real-world regressions (maybe in some macro-trickery crates?). Doing a crater run probably isn't worth it.

"incorrect UB when when a ! place is constructed (but not loaded!)" rust#117288

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

TC: @RalfJ found some interesting examples where rustc generates SIGILL on code that shouldn't have UB. T-compiler marked this P-high. RalfJ:

Nominating this to get first vibes on which of the following lines should be accepted, and which should be UB. (Currently they are all accepted and all UB but that's a bug.)

#![feature(never_type)]
fn deref_never<T>() {
    unsafe {
        let x = 3u8;
        let x: *const ! = &x as *const u8 as *const _;
        let _val = addr_of!(*x); // must be OK
        let _ = *x; // should probably be OK since we said `_` discards the place (and is UB-equivalent to `addr_of!`)
        let _: ! = *x; // does a no-op type annotation force the place to be loaded and hence cause UB?
        let _: () = *x; // is this UB? should we even accept such code?
        let _: String = *x; // what about this?
        let _: T = *x; // is this UB even if T = ! ?
    }
}

"Document that <- is a single token" reference#1424

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

TC: The question is whether to add this line to the reference:

| <- | LArrow | The left arrow symbol has been unused since before Rust 1.0, but it is still treated as a single token

The background, per mattheww, is that:

<- was the "move operator", removed in Rust 0.5, but is still lexed as a single token.

ehuss notes:

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

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.

Back in 2018, Niko had said:

Discussed in the @rust-lang/compiler meeting. I think we reached this consensus:

• in this case, yes, we should do as @petrochenkov suggests: keep parsing, error in AST validation
• if in the future, if it happens that we want to repurpose the syntax, we deal with it then: best of course is to use an edition for it, but maybe by then there no longer exist crates using it
• going forward, it would be ideal if we could do some kind of "pre-cfg / expansion" feature check to try and avoid this in the future; that may or may not be feasible though, and we couldn't do it retroactively for all existing things anyway

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

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

TC: @nikomatsakis gives this background:

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

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

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

TC: …and proposes that we adopt option 1.

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

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

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

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

TC: On that basis, @tmandry replied:

Nesting

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

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

warnings

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

Conclusion

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

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

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

static mut ARRAY: &'static mut [isize] = &mut [1];

However, we do not allow this:

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.

"TAIT decision on "may define implies must define"" rust#117861

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

TC: The question is whether this should be true:

At least until the new trait solver is stabilized, any item that is allowed to define the hidden type of some opaque type must define the hidden type of that opaque type.

TC: What this boils down to is whether we want to block TAIT on stabilizing the new trait solver. If we don't adopt this restriction, then T-types will not approve TAIT until the new trait solver lands.

TC: Here's the short version. The new trait solver treats strictly more code as being a defining use. It's also more willing to reveal the hidden type during inference if that hidden type is defined within the same body. This rule helps to avoid inference changes when moving from the old solver to the new solver.

TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque.)

"TAIT decision on "must define before use"" rust#117866

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

TC: The question is whether the following should be true:

If the body of an item that may define the hidden type of some opaque does define that hidden type, it must do so syntactically before using the opaque type in a non-defining way.

One of the big design questions on TAIT is whether we'll be able to later lift the "may define implies must define" rule after we land the new trait solver. The answer to that question could inform other design decisions, such as how to notate whether an item is allowed to define the hidden type of an opaque.

The restriction here is designed to make it more likely (hopefully much more likely) that we can later lift the "may define implies must define" restriction.

"TAIT decision on whether nested inner items may define" rust#117860

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

TC: The question is whether this should be true:

Unless and until RFC PR 3373 is accepted and scheduled for stabilization in some future edition, items nested inside of other items may define the hidden type for opaques declared outside of those items without those items having to recursively be allowed to define the hidden type themselves.

The context is that we allow this:

trait Trait {}
struct S;
const _: () = {
    impl Trait for S {} // Allowed.
};

Should we accept spiritually-similar TAIT code unless and until we decide to go a different direction with the language?

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

"Remove ability to disable some target features" rust#116584

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

TC: RalfJ nominated this one, and he has a corresponding design meeting proposal:

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

…

I have created a design meeting proposal for the wider problem space here, in case you think this needs more fundamental discussion.

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

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

"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. We did not come to any consensus other than that we were open to frontmatter in some form.

Action item review

• Action items list

Pending lang team project proposals

None.

PRs on the lang-team repo

"Add soqb`s design doc to variadics notes" lang-team#236

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

"Update auto traits design notes with recent discussion" lang-team#237

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

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

"make matching on NaN a hard error" rust#116284

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

"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

"Stabilise inline_const" rust#104087

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

"Implement PartialOrd and Ord for Discriminant" rust#106418

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

"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

"Exhaustiveness: reveal opaque types properly" rust#116821

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

"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

"Tracking issue for dyn upcasting coercion" rust#65991

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

"Stabilize C string literals" rust#117472

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

P-critical issues

None.