owned this note changed a year ago
Published Linked with GitHub

T-lang meeting agenda

  • Meeting date: 2024-03-13

Attendance

  • People: TC, pnkfelix, scottmcm, CE, Lukas Wirth, Santiago, tmandry, Josh, Waffle, Mara

Meeting roles

  • Minutes, driver: TC

Scheduled meetings

  • 2024-03-13: "Discuss the never type situation" #256
  • 2024-03-20: "Extended triage meeting 2024-03-20" #257

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

Guest attendee items

TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.

Moving right along

TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.

Lang oversight on int->ptr, ptr->int casts?

scottmcm: RalfJ has asked whether lang wants oversight on the documentation about these casts.

scottmcm: My view is that we have an RFC about this and that T-opsem can proceed on the details about this without us.

scottmcm: "transmute: caution against int2ptr transmutation" https://github.com/rust-lang/rust/pull/122379

scottmcm: If anyone has objections to this, it'd be good to mention that now.

Consensus: T-opsem can proceed on making changes to documentation consistent with the RFC we approved without further checkboxes from us on that documentation.

Design meeting at 12:30 EST / 09:30 PST / 17:30 CET

TC: Remember that our design meetings start half an hour earlier than in the past. For Europeans, note that for all of this month, all of our meetings start an hour earlier where you are.

RTN

TC: We had a call 2024-03-04 to discuss the syntax of RTN. There was no explicit consensus from that meeting, but the general mood was that there were two axes along which we might find consensus:

  • Axis 1: Whether to say () or (..) as sugar for ::Output.
  • Axis 2: Whether and how to distinguish the type namespace from the value namespace.

The next steps, per NM, are:

  • Author the RFC and kick-start public conversation.
  • Revise write-up focusing on the final decision space (the axes you mentioned above, for example).
    • and highlight the shared values that seemed to be popping up in people's write-ups.
  • Niko is mildly curious about gathering up some data e.g., doing some interviewing, I'm doing some thinking about this.

Rust 2024 review

Project board: https://github.com/orgs/rust-lang/projects/43/views/5

Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587

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

TC: We accepted the RFC and the implementation has landed for Rust 2024. We do need to stabilize some way of expressing precise capturing. That probably means stabilizing TAIT. We're starting with stabilizing ATPIT.

TC: That stabilization now on track. We're finishing some final items and are hopeful this may go into FCP soon.

Reserve gen keyword in 2024 edition for Iterator generators #3513

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

TC: We've done two recent things on this RFC:

  • Moved gen fn to be a future possibility.
  • Moved whether to support self-referential gen blocks to being an open question rather than a future possibility.

TC: That last change should resolve the open concern, which when done will cause this to move into FCP.

We've done the first. We'll do the second (it's currently listed as a future possibility).

TC: As an addendum to the discussion last week, we had discussed the possibility of reserving the yields keyword for gen closures, e.g.:

let _ = gen |x| yields u8 { todo!() };

TC: In discussion with Oli after the meeting, he pointed out that this is not needed, as even though this would appear in expressions, the keyword can and should be contextual because it's always appearing after gen |..|.

Tracking issue for promoting ! to a type (RFC 1216) #35121

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

TC: We'll be discussing this in the design meeting today. Waffle has put together a document for us.

Nominated RFCs, PRs, and issues

"Fallout from expansion of redundant import checking" rust#121708

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

TC: tmandry nominates this for us:

I've noticed there is a lot of fallout from the changes in #117772 expanding redundant import checking. See discussion and backlinks on that issue as well as #118692 for some evidence.

I have a theory that redundant imports should be split out into their own lint group (this was discussed in the past), and that in the future as a matter of policy, disruptive expansions like this should come with a machine-applicable fix to make rollout smoother.

For now, I'm opening this issue to collect data and feedback that I want to use to inform future policy discussions around lint expansions.

TC: What do we think?

tmandry: I'm looking for a vibe check on how people would feel about some kind of policy that might prevent this kind of disruption.

pnkfelix: Your proposal here would include adding a new name for the expansion then including it in a lint group?

tmandry: Yes, that'd be fine.

scottmcm: I'd be worried about a policy that would require a new lint in all cases. It'd be good if these expansions always had a machine-applicable fix though.

tmandry: It could be OK to either have a machine-applicable fix or to use a new name.

Josh: Would be in favor of a policy of "we should not do all three of 1) making a lint we expect to flag large amounts of existing code, 2) putting it under an existing lint name such that it's not trivial to turn off independently, and 3) not having a machine-applicable fix".

scottmcm: What I'm wondering most about that is the degree to which that is already the policy or the degree to which people just didn't expect the amount of impact that this lint had.

tmandry: I don't think there's a policy here.

scottmcm: The problem is that it'd be bad to require a new lint for each expansion, and it would be bad to require crater for each change to a lint.

CE: My feeling is that compiler maintainers do have a sense of this and are cautious about it. We could have a policy that's not perfectly measurable.

waffle: +1.

pnkfelix: In my mind, there are two things. One is trying to prevent these before they hit master. Then there's what we do after it hits master and people start filing bugs. Those bugs may have been a hint that we need to do something here. I like the idea of having a policy in place, but perhaps we don't need to prevent these from hitting master. We could handle these after that based on feedback.

tmandry: There's a weird incentive here that expanding an existing lint requires less process than creating a new one.

scottmcm: Agreed on that.

tmandry: I'll put together a policy proposal here.

"align_offset, align_to: no longer allow implementations to spuriously fail to align" rust#121201

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

TC: RalfJ had nominated this question for us, but it proceeded without us getting to it in a meeting, so I highlight it here for visibility. RalfJ:

this is not stabilizing anything t-lang-worthy immediately, but it still does make a decision we will be bound to: if we accept this change, then

  • either align_offset/align_to can never be called in const fn,
  • or we allow compile-time behavior to differ from run-time behavior.

So I will nominate for t-lang as well, with the question being: are you okay with accepting either of these outcomes (without committing to which one, just accepting that it has to be one of them)? This closes the door to "have align_offset and align_to at compile-time and also always have compile-time behavior match run-time behavior".

Josh:

With my lang hat on:

If I'm understanding correctly, these can differ at compile time precisely because the concept of addresses and them having alignment isn't the same at compile-time and runtime. That seems fine.

RalfJ:

Yes. The only time compile-time would give a "weird" answer is when the information required to give the expected answer is inherently unavailable at compile-time.

Josh:

We will still have options at compile-time; for instance, if we want to track the concept of "sufficiently aligned" at compile time, we could decide to do so in an abstract way.

RalfJ:

I think that might be tricky, e.g. if one crate declares a [u8; N] buffer stored somewhere then even tracking abstract alignment means downstream crates could be adding alignment constraints to that, e.g. deciding that it must be 4-aligned. I also don't think we actually want align_to to change the alignment of these static global objects.

TC: This sounds OK to us?

scottmcm: People have complained about align_to's documented behavior for ages. So this fixes that. We can add a different function later if necessary.

tmandry: Sounds good to me.

Consensus: We're OK with this having been merged and the consequences of that noted.

"Arbitrary self types v2" rfcs#3519

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

TC: We had a design meeting about this on 2024-02-28. The identified next step was to write up a list of the available options. That document is here:

https://hackmd.io/eXfrzrR7T1-3HVh6w5JMqA

The general mood in the meeting tended in the direction of doing the simpler thing for now (supporting only newtype wrappers) and saving space by giving a hard error on resolution ambiguity, but there were various concerns.

TC: I'm writing up a document to bring these together. So I may reach out to you to set up a call to be sure your views and concerns are faithfully represented.

TC: This came up in the RfL meeting also.

Josh: The RfL team thought that newtype wrappers would be OK for them. They also seemed cautiously positive about the derive(SmartPointer) idea that CE suggested, but would need to see the details.

TC: It'll probably fall on us to write out a proposal for derive(SmartPointer).

CE: (Discusses details of derive(SmartPointer).)

Josh: It's appealing that our macro here could check the invariants.

"regression: encountered mutable pointer in final value" rust#121610

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

TC: We discussed this in the meeting on 2024-03-06 but were unclear about the situation, particularly as it pertained to a decision we had earlier made here:

https://github.com/rust-lang/rust/pull/119044

TC: RalfJ has now written up a document for us about this:

https://hackmd.io/3fj1WHGIT7-l8hRHxcKS8A

TC: And I've scheduled for him and Oli to appear in our 90 minute extended triage meeting next week.

"restrict promotion of const fn calls" rust#121557

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

TC: RalfJ nominates this for us:

This PR aims to finally achieve the goal of the infallible promotion RFC. Originally the RFC said we should never promote operations that may panic or otherwise fail. We almost managed to do that, with one exception:

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  let x = &my_function();
  x
};

This would compile because we are promoting all calls to const fn in const/`static initializers. I tried a while ago to forbid this, which found 2 regressions. The regressed code didn't really have great alternatives to switch to (that would require inline consts), so I didn't pursue this further at the time, hoping to pick it up again when inline const get stabilized.

Unfortunately, years later, inline const are still not stable, and the longer the wait the bigger the risk that we'll never be able to fully make this transition and stop promoting function calls in const/static initializers. So this is my contingency plan: the actual goal of the "infallible promotion" RFC was to ensure that we can evaluate any const we see in a MIR body without worrying about whether that would lead to incorrect compilation failures (i.e., leading compilation to fail when it should not). This property is something we want as it means we can traverse the MIR for analyses and optimizations and just "look at" all consts without worrying about possible side-effects. We even guarantee that all consts one explicitly syntactically mentions in a function get evaluated, even in dead code, which is a pattern some crates rely on for soundnes. Promotion adds new consts, which is why it needs to be restricted, or else we need to carefully skip promoteds when evaluating all consts. The easiest way to achieve this is to ensure we only create promoteds that cannot fail, then they trivially cannot break this property. But there is another way: if we look again at the example above, then that program would fail to compile even if we didn't promote. In other words, promoting the &my_function() and then evaluating that promoted does not introduce an incorrect compilation failure! Only creating fallible promoteds in dead code can cause incorrect compilation failure.

So I propose that we achieve the goals of the RFC while maintaining compatibility as much as possible by only promoting function calls in const/static initializers if they are definitely not in dead code. This PR implements a fairly trivial way to achieve that: we walk the CFG of the initializer from the start block until the first branch (i.e., we walk down the "line" of basic blocks at the top that is formed by Goto and function calls), and all these blocks are definitely not dead. We only promote function calls in those blocks. This will miss blocks that are definitely not dead due to merging control flow (i..e, anything after the first if). But it turns out this is already sufficient to give us 0 crater regressions, so a more complicated analysis does not seem worth it.

In other words, the code above still compiles after this PR. The following code no longer compiles after this PR, and that is intended:

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  if false { // or any other condition
    let x = &my_function();
    x
  } else {
    &42
  }
};

The following code also no longer compiles after this PR, which is unfortunate but doesn't seem worth the effort of making it compile:

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  if true {} // or any other condition
  let x = &my_function();
  x
};

Maybe in a future edition we can entirely stop promoting function calls in const/static initializers. That is blocked on having inline consts. However, to make the desired property of being able to evaluate all consts we see actually useful to compiler developers, we need to achieve this property on all editions, so any such edition-related plan does not substitute a PR like this. Also, edition transitions for promotions are very hard (there is no plan for how one could possibly do automatic migration or future-compat lints), so I wouldn't want to bank on this.

I this pretty? No! Promotion rules are suddenly different in different parts of a const/static initializer. If I had a time machine I'd just make sure we never promote const fn calls to begin with. But mistakes were made and we have to live with them if we want to maintain compatibility. All we can do is mitigate the consequences of those mistakes, so I propose we add this new wart to the language to mitigate the problems caused by that old mistake. We already have value-dependent promotion (&(0/1) gets promoted but &(1/0) and &(0/(1*1)) do not, to make sure we do not promote a division by 0) now we add location-dependent promotion. In other words, promotion is already ugly, this just makes it a bit more ugly. I hope users will never run into this, and the fact that crater found no regressions makes me confident that this will at least be extremely rare.

If we ever get inline consts then we can consider cleaning up this mess by entirely stopping to promote function calls in const/static initializers, and accepting the breaking change. But I don't want to bet on the fact that we'll be able to do that, it's been years since the last crater run and the ecosystem has grown significantly since then. So this PR is forward-compatible with making things nice® again, but meanwhile accepting this PR ensures that MIR consumers can finally stop worrying about which consts they can or cannot evaluate.

scottmcm: This is part of the continuing saga. If we had const blocks we probably wouldn't need to do this. But it looks like RalfJ has found another bit that we can fix.

TC: We're blocked on const blocks by the check build regression.

scottmcm: We could just skip it in check builds. We accepted an RFC that said that we're allowed to do that. https://rust-lang.github.io/rfcs/3477-cargo-check-lang-policy.html

TC: I'll run that by Oli.

tmandry: That wouldn't be the end of the world.

Josh: We'd have to be careful because people use consts for static assertions.

scottmcm: Those would still probably be fine because they're item-level consts.

gen blocks

tmandry: On a bikeshed note. I'm having second thoughts about gen as a keyword. I'm curious what the RFC authors think about using generator.

TC: As one of the authors, my feeling is that gen fits better in the language given e.g. mod, fn, async, etc.

Josh: I think the concept of a generator is familiar to people. I think that generator would feel excessively long for e.g. generator closures. I do wish we could call this iter. But we probably can't do that because it'll break half the universe.

TC: The RFC authors also prefered iter but backed off of it for the reasons you mention.

tmandry: I'll post in the issue about it, but it doesn't need to block acceptance.

"Implement PartialOrd and Ord for Discriminant" rust#106418

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

TC: This has been on and off our radar. @scottmcm in particular has strong concerns about this that he first raised 5 years ago.

scottmcm:

I remain strongly opposed to anything that makes it impossible for a library author to leave open the door to reorder their enum variants later.

https://github.com/rust-lang/rust/pull/106418#pullrequestreview-1594299402

TC: Recently, T-libs-api decided to move forward on this:

We discussed this PR in today's T-libs-api meeting. Among the team members in the meeting (myself, Amanieu, Josh, Mara), we were still on board with unconditional Ord and PartialOrd impls; no need for a marker trait. Our approvals for the FCP are registered in #106418 (comment).

Exposing the discriminant order is the intended behavior. The documentation on mem::discriminant mentions that changing the definition of the enum can impact the order of discriminant values, and cites the Reference for detail on how discriminant values are assigned. Amanieu summarized the stability contract as being similar to transmute — the extent to which a caller gets to rely on particular properties across library versions is up to a contract between the caller and library author.

TC: tmandry has filed a concern:

Is it important that the discriminant order remain the same between different versions of the compiler? If not I'd like to document that it could change, and left a suggestion to that effect.

@rfcbot concern stability wrt compiler version

Otherwise this proposal looks good to me. Thanks for pushing it through.

TC: (In addition to tmandry, this one probably needs scottmcm present to discuss.)

TC: What do we think?

scottmcm: I need to turn my sketch into a proposal. This proposal probably covers this as well as the other issue. This proposal may cover all of the reasons that people want Ord on Discriminant, which would obviate this issue.

Josh: Please check back with the OP who proposed PartialOrd for Discriminant, to see if the proposed solution solves their problem. If it does, +1 for scott's solution, which looks quite elegant.

pnkfelix: (The reminds me of this old issue, back when I put in exactly the (big ugly) codegen scott described: https://github.com/rust-lang/rust/pull/15503)

tmandry: I think I can resolve my concern on this issue.

scottmcm: I'll file a concern on the issue about his alternate proposal.

Consensus: We'll wait for seeing the details of scottmcm's proposal.

(The meeting ended here.)

"Support ?Trait bounds in supertraits and dyn Trait under a feature gate" rust#121676

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

TC: This is related to this MCP:

https://github.com/rust-lang/compiler-team/issues/727

TC: The question here is whether we want to charter this as an experiment.

"Initial support for auto traits with default bounds" rust#120706

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

TC: This is related to this MCP:

https://github.com/rust-lang/compiler-team/issues/727

TC: The question here is whether we want to charter this as an experiment.

"Add simple async drop glue generation" rust#121801

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

TC: This is related to this MCP:

https://github.com/rust-lang/compiler-team/issues/727

TC: The question here is whether we want to charter this as an experiment.

"Consider linting against 00B7 aka interpunct aka middle dot" rust#120797

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

TC: In the meeting on 2024-02-21 we proposed to postpone this.

proposing that we not do this in uncommon_codepoints, and that we consider this again after we have the split-out lint that @Manishearth suggests in point 1 of #120228 (a lint about confusables with operator/punctuation).

TC: If others agree, this FCP can move forward.

"Tracking issue for function attribute #[coverage]" rust#84605

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

TC: This is about stabilizing a #[coverage(off)] attribute to exclude items from -Z instrument-coverage.

Josh proposed FCP merge and nominated this for us.

There are two open questions about applying this automatically to nested functions and to inlined functions.

TC: What do we think?

"is operator for pattern-matching and binding" rfcs#3573

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

TC: Josh proposes for us that we should accept:

if an_option is Some(x) && x > 3 {
    println!("{x}");
}

And:

func(x is Some(y) && y > 3);

TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.

TC: Earlier we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.

TC: What do we think, as a gut check?

"Should Rust still ignore SIGPIPE by default?" rust#62569

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

TC: Prior to main() being executed, the Rust startup code makes a syscall to change the handling of SIGPIPE. Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things like seccomp filters must be adjusted for this.

It's also just, in a practical sense, wrong for most CLI applications.

This seems to have been added back when Rust had green threads and then forgotten about. But it's been an ongoing footgun.

There was discussion in 2019 about fixing this over an edition, but nothing came of it.

TC: Are we interested in fixing it over this one?

"Stabilize #[unix_sigpipe = "sig_dfl"] on fn main()" rust#120832

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

TC: This is related to the above, and is a proposal to stabilize an option to have the startup code set SIGPIPE to the other handler. However, this does not address the problem that the Rust startup code is making this syscall at all, which means that e.g. seccomp filters must be correctly adjusted and it's still impossible to recover the original inherited setting of this handler.

There are also the following options to this attribute that are not proposed for stabilization here:

  • sig_ign: This is the current default behavior.
  • inherent: This would prevent the startup code from making this syscall at all.

TC: What do we think?

"offset: allow zero-byte offset on arbitrary pointers" rust#117329

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

TC: RalfJ nominates this for us:

Nominating for t-lang discussion. This implements the t-opsem consensus from rust-lang/opsem-team#10, rust-lang/unsafe-code-guidelines#472 to generally allow zero-sized accesses on all pointers. Also see the tracking issue.

  • Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer
  • Inbounds-offset-by-zero is allowed on all pointers, including the null pointer
  • offset_from on two pointers is always allowed when they have the same address (but see the caveat below)

This means the following function is safe to be called on any pointer:

fn test_ptr(ptr: *mut ()) { unsafe {
    // Reads and writes.
    let mut val = *ptr;
    *ptr = val;
    ptr.read();
    ptr.write(());
    // Memory access intrinsics.
    // - memcpy (1st and 2nd argument)
    ptr.copy_from_nonoverlapping(&(), 1);
    ptr.copy_to_nonoverlapping(&mut val, 1);
    // - memmove (1st and 2nd argument)
    ptr.copy_from(&(), 1);
    ptr.copy_to(&mut val, 1);
    // - memset
    ptr.write_bytes(0u8, 1);
    // Offset.
    let _ = ptr.offset(0);
    let _ = ptr.offset(1); // this is still 0 bytes
    // Distance.
    let ptr = ptr.cast::<i32>();
    ptr.offset_from(ptr);
} }

Some specific concerns warrant closer scrutiny.

LLVM 16

We currently still support LLVM 16, which does not yet have the patches that make getelementptr inbounds always well-defined for offset 0. The function above thus generates LLVM IR with UB. No known miscompilations arise from that, and my attempt at just removing the inbounds annotation on old versions of LLVM failed (I got segfaults, and Nikic suggested that keeping these attribute around is actually less risky than removing them). If we want to avoid this, we have to wait until support for LLVM 16 can be dropped (which apparently is in May).

Null pointers

t-opsem decided to allow zero-sized reads and writes on null pointers. This is mostly for consistency: we definitely want to allow zero-sized offsets on null pointers (ptr::null::<T>().offset(0)), since this is allowed in C++ (and a proposal is being made to allow it in C) and there's no reason for us to have more UB than C++ here. But if we allow this, and therefore consider the null pointer to have a zero-sized region of "inbounds" memory, then it would be inconsistent to not allow reading from / writing to that region.

offset_from

This operation is somewhat special as it takes two pointers. We do want test_ptr above to be defined on all pointers, so offset_from between two identical pointers without provenance must be allowed. But we also want to achieve this property called "provenance monotonicity", whereby adding arbitrary provenance to any no-provenance pointer must never make the program UB.1 From these two it follows that calling offset_from with two pointers with the same address but arbitrary different provenance must be allowed. This does have some minor downsides. So my proposal (and this goes beyond what t-opsem agreed on) is to define the ptr_offset_from intrinsic to satisfy provenance monotonicity, but to document the user-facing ptr.offset_from(...) as requiring either two pointers without provenance or two pointers with provenance for the same allocation therefore, making the case of provenance mismatch library UB, but not language UB.

Footnotes

  1. This property should hopefully make some intuitive sense, and it is also crucial to justify optimizations that make the program have more provenance than before such as optimizing away provenance-stripping operations. Specifically, *ptr = *ptr where ptr: *mut usize is likely going to be a provenance-stripping operation, and so optimizing away this redundant assignment requires provenance monotonicity.

TC: What do we think?

"Let's #[expect] some lints: Stabilize lint_reasons (RFC 2383) " rust#120924

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

TC: Since the last time this was proposed for stabilization, various unresolved questions have now been resolved, so this is being proposed again.

Hey everyone, with the #[expect] implementation done, I'd like to propose stabilizing this feature. I've crated two stabilization PRs, one updating the documentation and one removing the feature from rustc:

The RFC 2383 adds a reason parameter to lint attributes and a new #[expect()] attribute to expect lint emissions.

  • Here is an example how the reason can be added and how it'll be displayed as
    part of the emitted lint message:
#![feature(lint_reasons)]
fn main() {
    #[deny(unused_variables, reason = "unused variables, should be removed")]
    let unused = "How much wood would a woodchuck chuck?";
}
error: unused variable: `unused`
 --> src/main.rs:5:9
  |
5 |     let unused = "How much wood would a woodchuck chuck?";
  |         ^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused`
  |
  = note: unused variables, should be removed
note: the lint level is defined here
 --> src/main.rs:4:12
  |
4 |     #[deny(unused_variables, reason = "unused variables, should be removed")]
  |            ^^^^^^^^^^^^^^^^
  • Here is an example, that fulfills the expectation and compiles successfully:
#![feature(lint_reasons)]
fn main() {
    #[expect(unused_variables, reason = "WIP, I'll use this value later")]
    let message = "How much wood would a woodchuck chuck?";

    #[expect(unused_variables, reason = "is this unused?")]
    let answer = "about 700 pounds";
    println!("A: {answer}")
}
warning: this lint expectation is unfulfilled
 --> src/main.rs:4:14
  |
6 |     #[expect(unused_variables, reason = "is this unused?")]
  |              ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default
  = note: is this unused?

Changes from the RFC

As part of my implementation, I renamed the #[expect] lint from expectation_missing to unfulfilled_lint_expectations. I think the name works better with other lint attributes and is more descriptive.

Resolutions of unresolved questions

  1. Where should the reason parameter be allowed?

    • The current implementation only allows it as the last parameter in all lint attributes
  2. How should #[expect(unfulfilled_lint_expectations)] be handled?

    • In the RFC, it was suggested that the unfulfilled_lint_expectations can be expected by outer attributes. However, it was also questioned how useful this would actually be. The current implementation doesn't allow users to expect this lint. For #[expect(unfulfilled_lint_expectations)] the lint will be emitted as usual, with a note saying that unfulfilled_lint_expectations can't be expected.
  3. How should #[expect(XYZ)] and --force-warn XYZ work?

    • This implementation, will emit the lint XYZ, as the lint level has been defined by --force-warn and also track the expectation as it usually would with only the #[expect] attribute.

Updates

Since the initial report, a few questions have been discussed by the lang team, here is a quick overview of the questions and resolutions:

  1. Should the attribute really be called #[expect] or is the name too generic?

  2. What are the semantics of the #[expect] attribute?

    • Decision: An expectation should count as fulfilled, if a #[warn] attribute at the same location would result in a lint emission (Decision)

Open issues

TC: What do we think?

"Lang discussion: Item-level const {} blocks, and const { assert!(...) }" lang-team#251

Link: https://github.com/rust-lang/lang-team/issues/251

TC: This issue was raised due to discussion in a T-libs-api call. Josh gives the context:

In discussion of rust-lang/libs-team#325 (a proposal for a compile-time assert macro), the idea came up to allow const {} blocks at item level, and then have people use const { assert!(...) }.

@rust-lang/libs-api would like some guidance from @rust-lang/lang about whether lang is open to toplevel const { ... } blocks like this, which would influence whether we want to add a compile-time assert macro, as well as what we want to call it (e.g. static_assert! vs const_assert! vs some other name).

Filing this issue to discuss in a lang meeting. This issue is not seeking any hard commitment to add such a construct, just doing a temperature check.

CAD97 noted:

To ensure that it's noted: if both item and expression const blocks are valid in the same position (i.e. in statement position), a rule to disambiguate would be needed (like for statement versus expression if-else). IMO it would be quite unfortunate for item-level const blocks to be evaluated pre-mono if that same const block but statement-level would be evaluated post-mono.

Additionally: since const { assert!(...) } is post-mono (due to using the generic context), it's potentially desirable to push people towards using const _: () = assert!(...); (which is pre-mono) whenever possible (not capturing generics).

TC: What do we think?

"add float semantics RFC" rfcs#3514

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

TC: In addition to documenting the current behavior carefully, this RFC (per RalfJ)

says we should allow float operations in const fn, which is currently not stable. This is a somewhat profound decision since it is the first non-deterministic operation we stably allow in const fn. (We already allow those operations in const/static initializers.)

TC: What do we think? tmandry proposed this for FCP merge back in October 2023.

"Don't make statement nonterminals match pattern nonterminals" rust#120221

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

TC: CE handed this one to us, since it changes the contract of macro matchers:

Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to may_be_ident.

This has the unfortunate side effect that a stmt nonterminal eagerly matches against a pat nonterminal, leading to a parse error:

macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
    };
}

m2! { let x = 1 }

This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.

As a side-effect, I modified Token::can_begin_pattern to work correctly and used that in Parser::nonterminal_may_begin_with.

TC: What do we think?

"RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556

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

TC: This seems to be about making the following work:

// kind is optional if it's been specified elsewhere, e.g. via the `-l` flag to rustc
#[link(name="ext", kind="static")]
extern {
    #[no_mangle]
    pub fn foo();

    #[no_mangle]
    pub static bar: std::ffi::c_int;
}

There are apparently use cases for this.

What's interesting is that apparently it already does, but we issue a warning that is wrong:

warning: `#[no_mangle]` has no effect on a foreign function
  --> src/lib.rs:21:5
   |
21 |     #[no_mangle]
   |     ^^^^^^^^^^^^ help: remove this attribute
22 |     pub fn foo_rfc3556_pub_with_no_mangle();
   |     ---------------------------------------- foreign function
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: symbol names in extern blocks are not mangled

TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).

TC: What do we think?

"Tracking Issue for unicode and escape codes in literals" rust#116907

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

TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:

I have a partial implementation of this RFC working locally (EDIT: now at #120286). The RFC proposes five changes to literal syntax. I think three of them are good, and two of them aren't necessary.

TC: What do we think?

"Better errors with bad/missing identifiers in MBEs" rust#118939

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

TC: The idea here seems to be to improve some diagnostics around macro_rules, but this seems to be done by way of reserving the macro_rules token more widely, which is a breaking change. Petrochenkov has objected to it on that basis, given that reserving macro_rules minimally has been the intention since we hope it will one day disappear in favor of macro. What do we think?

"unsafe attributes" rfcs#3325

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

TC: tmandry nominated this one for us so that we could finish the bikeshed that we started in time for Rust 2024.

Lokathor laid out these options:

The three basic proposals are:

  • #[unsafe attr] ("unsafe space")
  • #[unsafe(attr)] ("unsafe parens")
  • #[unsafe { attr }] ("unsafe braces")

During the lang meeting on 2023-06-06, it was requested that a summary of how each option actually looks in practice be made,so that hopefully one of the proposals can be selected based on readability.

When using an attribute, the attribute itself can be one of three basic forms:

  • lone token: #[no_mangle]

    • #[unsafe no_mangle]
    • #[unsafe(no_mangle)]
    • #[unsafe { no_mangle }]
  • key-val expression: #[link_section = ".foo"]

    • #[unsafe link_section = ".foo"]
    • #[unsafe(link_section = ".foo")]
    • #[unsafe { link_section = ".foo" }]
  • an attribute "call": #[link_ordinal(15)]

    • #[unsafe link_ordinal(15)]
    • #[unsafe(link_ordinal(15))]
    • #[unsafe { link_ordinal(15) }]

There is also the issue of readability when mixed with cfg_attr.

  • Interior, around only the attribute:

    • #[cfg_attr(cond, unsafe no_mangle)]
    • #[cfg_attr(cond, unsafe(no_mangle)]
    • #[cfg_attr(cond, unsafe { no_mangle } )]
  • Exterior, around the cfg_attr:

    • #[unsafe cfg_attr(cond, no_mangle)]
    • #[unsafe(cfg_attr(cond, no_mangle))]
    • #[unsafe { cfg_attr(cond, no_mangle ) }]

TC: This is an interesting case because we are not discharging unsafety, as with unsafe { expr } in a function body. Neither does saying unsafe here create and push upward a type-checked obligation. Instead, the upward obligation exists regardless and there is no means to signal to the compiler that it has been discharged and no enforcement of that.

TC: Another option I've seen discussed is finding some way to make these annotations safe.

TC: What do we think?

TC: A poll was opened about this question here:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unsafe.20attribute.20syntax

TC: While obviously such voting is not dispositive, it is perhaps at least worth noting that sentiment was strongly in favor of #[unsafe(no_mangle)].

"Add lint against function pointer comparisons" rust#118833

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

TC: In the 2024-01-03 call, we developed a tentative consensus to lint against direct function pointer comparison and to push people toward using ptr::fn_addr_eq. We decided to ask T-libs-api to add this. There's now an open proposal for that here:

https://github.com/rust-lang/libs-team/issues/323

One question that has come up is whether we would expect this to work like ptr::addr_eq and have separate generic parameters, e.g.:

/// Compares the *addresses* of the two pointers for equality,
/// ignoring any metadata in fat pointers.
///
/// If the arguments are thin pointers of the same type,
/// then this is the same as [`eq`].
pub fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool { .. }

Or whether we would prefer that fn_addr_eq enforced type equality of the function pointers. Since we're the ones asking for this, we probably want to develop a consensus here. We discussed this in the call on 2024-01-10, then we opened a Zulip thread:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Signature.20of.20.60ptr.3A.3Afn_addr_eq.60

TC: On this subject, scottmcm raised this point, with which pnkfelix seemed to concur:

I do feel like if I saw code that had fn1.addr() == fn2.addr() (if FnPtr were stabilized), I'd write a comment saying "isn't that what fn_addr_eq is for?"

If the answer ends up being "no, actually, because I have different types", that feels unfortunate even if it's rare.

(Like how addr_eq(a, b) is nice even if with strict provenance I could write a.addr() == b.addr() anyway.)

TC: scottmcm also asserted confidence that allowing mixed-type pointer comparisons is correct for ptr::addr_eq since comparing the addresses of *const T, *const [T; N], and *const [T] are all reasonable. I pointed out that, if that's reasonable, then ptr::fn_addr_eq is the higher-ranked version of that, since for the same use cases, it could be reasonable to compare function pointers that return those three different things or accept them as arguments.

TC: Adding to that, scottmcm noted that comparing addresses despite lifetime differences is also compelling, e.g. comparing fn(Box<T>) -> &'static mut T with for<'a> fn(Box<T>) -> &'a mut T.

TC: Other alternatives we considered were not stabilizing ptr::fn_addr_eq at all and instead stabilizing FnPtr so people could write ptr::addr_eq(fn1.addr(), fn2.addr()), or expecting that people would write instead fn1 as *const () == fn2 as *const ().

TC: Recently CAD97 raised an interesting alternative:

From the precedent of ptr::eq and ptr::addr_eq, I'd expect a "ptr::fn_eq" to have one generic type and a "ptr::fn_addr_eq" to have two. Even if ptr::fn_eq's implementation is just an address comparison, it still serves as a documentation point to call out the potential pitfalls with comparing function pointers.

TC: What do we think?


TC: Separately, on the 2024-01-10 call, we discussed some interest use cases for function pointer comparison, especially when it's indirected through PartialEq. We had earlier said we didn't want to lint when such comparisons were indirected through generics, but we did address the non-generic case of simply composing such comparisons.

One example of how this is used is in the standard library, in Waker::will_wake:

https://doc.rust-lang.org/core/task/struct.Waker.html#method.will_wake

It's comparing multiple function pointers via a #[derive(PartialEq)] on the RawWakerVTable.

We decided on 2024-01-01 that this case was interesting and we wanted to think about it further. We opened a discussion thread about this:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Function.20pointer.20comparison.20and.20.60PartialEq.60

Since then, another interesting use case in the standard library was raised, in the formatting machinery:

https://doc.rust-lang.org/src/core/fmt/rt.rs.html

What do we think about these, and would we lint on derived PartialEq cases like these or no?

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

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

TC: This has been changed to use --- syntax with an optional infostring (that is arbitrary except for forbidding whitespace and commas).

TC: tmandry, Josh, and I are +1. What do we think?

"Uplift clippy::invalid_null_ptr_usage lint" rust#119220

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

TC: Urgau proposes this for us:

This PR aims at uplifting the clippy::invalid_null_ptr_usage lint into rustc, this is similar to the clippy::invalid_utf8_in_unchecked uplift a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.

invalid_null_ptr_usages

(deny-by-default)

The invalid_null_ptr_usages lint checks for invalid usage of null pointers.

Example

// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }

Produces:

error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`

Explanation

Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.

The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a #[diagnostic] attribute.

TC: What do we think?

"#[cold] on match arms" rust#120193

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

TC: Apparently our unstable likely and unlikely intrinsics don't work. There's a proposal to do some work on fixing that and stabilizing a solution here. The nominated question is whether we want to charter this as an experiment.

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

TC: There's now been a crater run done for this. The result was that this breaks a small number of crates, but at least one of those crates has a large number of dependents (aws-smithy-runtime). It can be fixed in the dependency in such a way that dependent crates do not have to make changes, but those dependent crates would need to update to a fixed version of the dependency.

(See this discussion.)

TC: What do we think?

"Add wasm_c_abi future-incompat lint" rust#117918

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

TC: daxpedda gives the context:

This is a warning that will tell users to update to wasm-bindgen v0.2.88, which supports spec-compliant C ABI.

The idea is to prepare for a future where Rust will switch to the spec-compliant C ABI by default; so not to break everyone's world, this warning is introduced.

Addresses https://github.com/rust-lang/rust/issues/71871

TC: Is this something we want to do?

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

TC: What do we think?

"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 (e.g. !, *, &)?

"Raw Keywords" rfcs#3098

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

"Tracking issue for RFC 2102, "Unnamed fields of struct and union type"" rust#49804

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

"Stabilize extended_varargs_abi_support" rust#116161

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

"Stabilize associated type position impl Trait (ATPIT)" rust#120700

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

"debuginfo: Stabilize -Z debug-macros, -Z collapse-macro-debuginfo and #[collapse_debuginfo]" rust#120845

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

"False positives for the new non_local_definitions lint" rust#121746

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

"Elaborate on the invariants for references-to-slices" rust#121965

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

"#![crate_name = EXPR] semantically allows EXPR to be a macro call but otherwise mostly ignores it" rust#122001

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

"Proposal: Remove i128/u128 from the improper_ctypes lint" lang-team#255

Link: https://github.com/rust-lang/lang-team/issues/255

"Decision on "must define before use" for opaque types" rust#117866

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

TC: The question is whether to adopt the following "must define before use" rule for opaque types:

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.

This is a breaking change to RPIT. Here's an example of code that works today that would break under this rule:

use core::convert::identity;

struct I;
struct IShow;
impl I { fn show(&self) -> IShow { IShow } }

struct OnIShow;
trait OnI { fn show(&self) -> OnIShow { OnIShow } }
impl OnI for I {}

fn test(n: bool) -> impl OnI {
    let true = n else { loop {} };
    let x = test(!n); //~ NOTE this is the opaque type
    let _: OnIShow = x.show(); //~ NOTE this is a non-defining use
    //~^ ERROR if the body registers a hidden type for the opaque, it
    //         must do so *before* using it opaquely
    let _: IShow = identity::<I>(x).show();
    //~^ NOTE this registers a hidden type for the opaque, but does so
    //        too late
    loop {}
}

fn main() {}

This rule has relevance to the new trait solver.

TC: What do we think?

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

"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: This is important for the new trait solver.

TC: Here's one reason for that. 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. Adding this restriction makes TAIT roughly equivalent to RPIT with respect to these challenges.

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 "may not 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: This is of importance to the new trait solver.

TC: Here's one reason for this. 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? Depending on that, we can get different answers.

TC: If we did not let inference rely on this, then we would be closing the door on later allowing inference to rely on this without provoking changes in inference.

TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque. Answering this question in the affirmative would update one element of the #107645 FCP.)

Action item review

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

"RFC: patchable-function-entry" rfcs#3543

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

S-waiting-on-team

"[ptr] Document maximum allocation size" rust#116675

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

"warn less about non-exhaustive in ffi" rust#116863

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

"offset: allow zero-byte offset on arbitrary pointers" rust#117329

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

"Add wasm_c_abi future-incompat lint" rust#117918

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

"Rename AsyncIterator back to Stream, introduce an AFIT-based AsyncIterator trait" rust#119550

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

"privacy: Stabilize lint unnameable_types" rust#120144

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

"Don't make statement nonterminals match pattern nonterminals" rust#120221

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

"debuginfo: Stabilize -Z debug-macros, -Z collapse-macro-debuginfo and #[collapse_debuginfo]" rust#120845

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

"restrict promotion of const fn calls" rust#121557

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

"Allow #[deny] inside #[forbid] as a no-op with a warning" rust#121560

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

"Split refining_impl_trait lint into _reachable, _internal variants" rust#121720

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

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 text for the CFG OS Version RFC" rfcs#3379

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

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

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

"Reserve gen keyword in 2024 edition for Iterator generators " rfcs#3513

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

"add float semantics RFC" rfcs#3514

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

"RFC: New range types for Edition 2024" rfcs#3550

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

"Tracking issue for function attribute #[coverage]" rust#84605

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

"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

"[ptr] Document maximum allocation size" rust#116675

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

"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

"Add REDUNDANT_LIFETIMES lint to detect lifetimes which are semantically redundant" rust#118391

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

"privacy: Stabilize lint unnameable_types" rust#120144

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

"Stabilize associated type position impl Trait (ATPIT)" rust#120700

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

"Allow #[deny] inside #[forbid] as a no-op with a warning" rust#121560

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

"regression: let-else syntax restriction (right curly brace not allowed)" rust#121608

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

Active FCPs

"Tracking issue for Allow a re-export for main (RFC 1260)" rust#28937

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

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

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

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

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

"Add wasm_c_abi future-incompat lint" rust#117918

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

"Consider linting against 00B7 aka interpunct aka middle dot" rust#120797

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

"debuginfo: Stabilize -Z debug-macros, -Z collapse-macro-debuginfo and #[collapse_debuginfo]" rust#120845

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

"Split refining_impl_trait lint into _reachable, _internal variants" rust#121720

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

"Stabilize associated type bounds (RFC 2289)" rust#122055

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

P-critical issues

None.

Select a repo