T-lang meeting agenda

Meeting date: 2024-01-03

Attendance

People: TC, NM, tmandry, pnkfelix, Josh, Urgau

Meeting roles

Minutes, driver: TC

Scheduled meetings

2024-01-03: Planning meeting

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

Announcements or custom items

(Meeting attendees, feel free to add items here!)

Nominated RFCs, PRs, and issues

"Add `AsyncFn` family of traits" rust#119305

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

TC: CE is proposing to add "a new family of asynchronous Fn-like traits to the standard library for experimentation purposes."

TC: These are all lang items and use the special arrow syntax. Do we want to charter this as a T-lang experiment?

NM: I'm definitely in favor. Discussed it with CE recently. We sketched out an MVP of async closure support. We don't have to solve the integration with the Fn traits on day 1.

JT: Definitely in favor of experimentation. Could we get some context on why we need separate AsyncFn* traits rather than Fn(...) -> impl Future<...>?

NM: The output of Fn traits aren't GATs. So it can't borrow from Self, which we need for a future; the result wouldn't work the way you would expect.

JT: +1 for experimentation. Usual experiment requirements: should be marked as incomplete feature until RFCed.

NM: I'll liaison.

Consensus: We'll charter this as a T-lang experiment.

"Avoid non-local definitions in functions" rfcs#3373

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

TC: The nominated question from tmandry is roughly, "where is this with respect to Rust 2024?"

TC: As far as I know, there hasn't been movement on this since February.

Felix: Quick note: ekuber and I discovered other probable-undesirable variants of this, like allowing impl items in const blocks.

JT: No additional context here, but happy to update the RFC based on whatever we decide.

tmandry: Was just hoping for a straw poll here. It's probably a more complicated change than it first seems on the surface.

JT: It's certainly not trivial. If we were going to do it, we'd probably want the RFC merged in the next week or two.

tmandry: We may need to replace uses of this with things like an anonymous module.

Felix: This is used in const initializers also.

TC: That's actually used for hygiene in macros.

NM: I'm a bit worried about this. First of all, I'm unconvinced that this is as important as people think it is for performance. Secondly, I'm worried about fallout from trying to drive this, e.g. for the reason that TC noted.

NM: If they're even tokenizing, as they have to do, then's probably an 80/20 thing that tools like RA could do.

JT: There are two potential benefits to this. One is simplifying things for IDEs. The other is simplifying it for humans. The second is the more important reason for me.

pnkfelix: But that could be a lint. My feeling is that if we do anything at all, it should start as a lint.

NM: It seems like a lint could have a lot of the benefit.

JT: Certainly if we were to add a lint it would cause us to learn about the potential cases.

NM/tmandry: +1.

pnkfelix: Clippy first?

JT: That would be too slow.

JT: I'd be happy to update the RFC to say that we add a deny-by-default lint for this, then we could reevaluate in 2027.

TC: Is deny-by-default too strong to start?

pnkfelix: I'd start with warn-by-default.

NM: Warn-by-default seems better. This seems similar, e.g., to warning about pub not reachable from the crate root.

JT: deny-by-default we could do with the 2024 edition.

JT: I'll propose warn-by-default in all editions, we'll later evaluate deny-by-default for 2024, and we'll reevaluate forbid for 2027.

Consensus: As above.

"RFC: constants in patterns" rfcs#3535

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

TC: On the basis of our 2023-10-18 design meeting, RalfJ wrote up this RFC and nominated it for us.

TC: Probably everyone should have a look asynchronously. I've bumped a thread to remind us about that, and to give a place for us to leave any notes we might want to discuss in a triage meeting:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/RFC.20for.20constants.20in.20patterns/near/409148153

TC: Any progress we can make here?

JT: Is this an edition change or across the board.

TC/NM: It's across-the-board.

NM: It's only breaking code against which we already lint.

JT: It'd be good to have data on how much it breaks.

tmandry: Do we want to handle that with the RFC, or upon the stabilization PR?

JT: Agreed, we could do that on stabilization. I'll propose RFC merge.

NM: I note that this RFC continues to require #[derive(PartialEq)]. I think I'm OK with accepting it. But we should make a TODO about this.

tmandry: This is noted as a drawback in the RFC.

NM: How committed are we to that at the moment? I'll ask a question about that.

Consensus: Let's proposed FCP merge, and Niko will ask a question on the issue.

"const-eval interning: get rid of type-driven traversal" rust#119044

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

TC: On 2023-12-20, we discussed work from @RalfJ to replace the const-eval interner. The T-lang side of this was that this code…

const CONST_RAW: *const Vec<i32> = &Vec::new() as *const _;

…which is currently rejected would now be accepted.

We were a bit unclear about why this was rejected today and why it would be accepted after this change, so we asked @RalfJ to explain it to us. He has helpfully now done that here.

The high level view is that the old interner – the thing that picks where to put static and const values in the final binary – did a type-based traversal of the value, and if during that traversal it found raw pointers, references inside a union, etc. that would need to be interned, for const items, it would later throw up its hands.

The new interner just directly traverses the pointers to ensure that at every level things make sense, e.g. that all pointers to newly interned allocations must be immutable.

This is why the code above is now accepted. The new interner finds an immutable pointer to read-only memory and decides reasonably that this is OK.

The door we'd be closing, per @RalfJ, is that:

Accepting this code pretty much commits us to non-type-based interning, but I think that's the better strategy anyway.

What do we think?

NM: For this to work, Vec::new has to be const fn, of course. So what's the SemVer hazard? Is there one? You can't change Vec to always allocate, but I don't think you could have a const fn new that allocates anyway.

pnkfelix: If what RalfJ said here is true, this sounds safe to me.

pnkfelix: Is it true we don't allow &mut in const eval?

NM: There is an example of a rejected use of &mut in RalfJ's comment.

pnkfelix: I'll follow up and test the PR to ensure that the cases I'm worried about are handled correctly.

NM: I think there is precedent for this (e.g., you can create a None::<T> for any T in a constant) and that we should do it.

tmandry: There's nothing here that concerns me.

TC: Do we want to FCP merge and file a concern for pnkfelix to have a look?

pnkfelix: The more I read through this, the more comfortable I feel with it. I'm OK with FCP, then I'll file a concern if I want to.

tmandry: I'll propose FCP merge.

Consensus: Let's propose FCP merge.

"Add lint against function pointer comparisons" rust#118833

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

TC: We discussed this on 2023-12-13. There was some support for this, but people were concerned about whether there may be legitimate use cases and what we would be suggesting that those people do instead. For wide pointer comparisons, we suggest that people use ptr::addr_eq even though that has the same problems as comparison with == as it at least makes the intent of the user clear. What would be the comparable thing we would do here?

We discussed that seeing use cases would help, and that a crater run would help to find those use cases. We were looking to find 1) use cases of this that are correct in the sense that they rely only on the actual semantics, and 2) the prevalence of bugs where people are using this in ways that rely on semantics that do not actually hold.

We also discussed that:

Comparing functions for equality via pointers may yield false negatives but not false positives. The fact that two functions may compare unequal (based on pointers to them) but in fact do the same thing is a rather fundamental property of not just Rust, but of any language. In general, it's impossible to know whether two different functions may in fact do the same thing.

In this light, maybe it's OK that these comparisons produce false negatives, and maybe there exist valid use cases that only rely on the property that we will not return false positives.

However, RalfJ has pointed out:

That's not true. There are both false negatives and false positives. That's exactly why I wanted the lint description to be clear about this.

False positives arise when LLVM merges two functions because they optimized to the same code.

TC: A crater run has now been performed and analyzed by Urgau:

https://github.com/rust-lang/rust/pull/118833#issuecomment-1872961055

Observations

Some false positives, mainly when filtering fn-ptrs within a vector.

Many true-positives, the vast majority when comparing a fn-ptr with a fn-def.

Requiring that one of the operands is an fn-def may be a good compromise.

TC: What do we think?

pnkfelix: If two functions compile to the same thing, they have the same behavior, so is it really a false positive?

NM: But it would be a weird SemVer thing.

Josh: Not sure this should be considered any kind of semver guarantee.

tmandry: And there would be issues with the types and maybe the ABI.

pnkfelix: I subscribe to the idea that the only thing you can do with a function pointer is call it. So if the behavior is the same, then maybe it's the same.

JT: There are two possible views of function pointers. One is that function pointers with the same address are the same function. The other is that we have a more enriched view of them, in which case we can we can never compare them at all.

NM: What are we trying to decide?

pnkfelix: Are we trying to push people against function pointer comparisons?

NM: And push them toward a named function?

TC: But there isn't a named function for this.

NM: Yes, that's a good point. ptr::addr_eq is probably not right here. We'd need e.g. ptr::func_eq or similar.

NM: I could imagine writing unsafe code with an Any like pattern that concludes on the basis of function pointer equality that a transmute would be OK. That would be wrong of course.

tmandry: The crater run did find cases where people used this wrong.

NM: This is a difficult one. What did we mean by "true positive" in the crater analysis.

Urgau: The true positive is when it's a bug.

NM: What makes it a bug?

Urgau: In many cases it's a bug because the codegen could be different.

NM: The behavior will be different depending on the compliation settings.

pnkfelix: Should the lint actually be comparing a function pointer to a function definition?

Urgau: There is a clippy lint that uses that semantic. I think this is a good approach.

NM: The idea here is that such a pattern is very likely to be wrong because the def could be coming from one compilation unit and the pointer could be coming from a different one.

NM: It seems like a good starting point.

pnkfelix: There's a big picture policy question that the PR is getting at. Do we want to push people away from comparing all function pointers?

NM: There's the question of whether we're committed to the current semantics, and there's the question of how we want to direct people.

NM: I feel like there is no world in which we can reject function pointer comparisons. So the only question is how hard we want to lint.

JT: In terms of an opt-in for people who know the risks, the obvious one would be to use a function for this.

pnkfelix: Do we have a way to write a signature for such a function that would be appropriately restricted?

NM: No. We're working on that.

NM: We'd need something in the signature like T: FnPtr.

JT: Would this still permit the usage of the PartialEq and PartialOrd impls?

NM: Yes.

NM: IF you want a map that uses address equality, there's no other way to write that.

tmandry: I'm fine with this direction.

Consensus: We prefer to have a fn_addr_eq function and lint against direct function pointer comparison with == and push people toward using the method. Let's start by asing T-libs-api to add this function for us.

Urgau: I'll file the issue for this.

https://doc.rust-lang.org/std/marker/trait.FnPtr.html

mod ptr {
    /// Compares two function pointers for address equality.
    ///
    /// (describe surprising semantics, in particular how it is dependent on CGU + optimization + etc)
    ///
    /// This is the same as `f == g` but using this function makes clear
    /// that you are aware of these potentially surprising semantics.
    #[allow(fn_pointer_comparison)]
    fn fn_addr_eq<T>(f: T, g: T) where T: FnPtr {
        f == g
    }
}

"Warn on references casting to bigger memory layout" rust#118983

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

TC: Urgau nominated this for us:

This PR extends the invalid_reference_casting lint (deny-by-default) which currently lint on &T -> &mut T casting (as well as when assigning to &T) to also lint on &(mut) A -> &(mut) B where size_of::<B>() > size_of::<A>() (bigger memory layout requirement).

The goal is to detect such cases:
let u8_ref: &u8 = &0u8;
let u64_ref: &u64 = unsafe { &*(u8_ref as *const u8 as *const u64) };
//~^ ERROR casting references to a bigger memory layout is undefined behavior

let mat3 = Mat3 { a: Vec3(0i32, 0, 0), b: Vec3(0, 0, 0), c: Vec3(0, 0, 0) };
let mat3 = &*(&mat3 as *const _ as *const [[i64; 3]; 3]);
//~^ ERROR casting references to a bigger memory layout is undefined behavior
One caveat, due to the &Header uncertainty the lint only fires when it can find the underline allocation.

TC: What do we think?

JT: If you take a local u8 and turn that into &u64, we can tell that's a bad idea. Though there are still cases where we may not be able to tell.

NM: Will this occur if you also cast through a raw pointer? I commonly have a raw pointer to unit, e.g.

JT: The only time we'd warn is when you're casting a reference to an allocation we can see into a reference that would exceed that allocation.

NM: That seems reasonable then. Lacking some way to express that I know what I'm doing, I'd like a more targetted lint.

tmandry: I'll propose FCP merge.

Consensus: Let's do this.

(The meeting ended here.)

"UnsafeCell::raw_get: use raw pointer self type" rust#118806

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

TC: RalfJ nominated this for us:

Back in the day we made this an associated function to avoid relying on raw-ptr self types. I'd like to know if that is still a concern – I hope we can stabilize #74265 and #71146 soon, and while strangely those do not require the arbitrary_self_types feature, I would think that for the compiler and type system those are very similar cases. So I'd like to see if we are comfortable having stable methods with raw pointer self types. I expect this will need t-lang FCP (and t-libs-api), and also t-types involvement.

TC: What do we think?

"Detect `NulInCStr` error earlier." rust#119172

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

TC: nnethercote nominated this for us:

[Detect NulInCStr error earlier by] making it an EscapeError instead of a LitError. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars.

NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together.

One nice thing about this: the old approach had some code in report_lit_error to calculate the span of the nul char from a range. This code used a hardwired +2 to account for the c" at the start of a C string literal, but this should have changed to a +3 for raw C string literals to account for the cr", which meant that the caret in cr" nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error.

In short, the delayed C NUL str check is inconsistent with all other string literal checks. If it ships in its current state, we're stuck with that behaviour permanently. If we move it earlier right now before it ships, we have the option to delay it (and all other string literal checks) later on (as implemented in #118699). So if we do this in the next few days, we avoid a one-way door shutting.

(This also has some relationship with: https://github.com/rust-lang/rust/pull/118699)

TC: On the basis of this observation, we decided to revert the stabilization of C string literals from Rust 1.76:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rfc.203349.3A.20mixed.20utf8.20literals

TC: However, we still need to decide the issue before we can move to restabilize. 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?

"`refining_impl_trait` only fires on public traits" rust#119535

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

TC: We recently in Rust 1.75 stabilized RPITIT/AFIT. Along with that, somewhat unusually, we stabilized two "please confirm you understand how Rust works" lints against the new feature.

One lint is async_fn_in_trait:

pub trait Foo {
    async fn foo() -> impl Sized;
    //~^ WARN use of `async fn` in public traits is discouraged as auto trait bounds cannot be specified
    //~| NOTE you can suppress this lint if you plan to use the trait only in your own code, or do not care about auto traits like `Send` on the `Future`
    //~| NOTE `#[warn(async_fn_in_trait)]` on by default
    //~| HELP you can alternatively desugar to a normal `fn` that returns `impl Future` and add any desired bounds such as `Send`, but these cannot be relaxed without a breaking API change
}

The other is refining_impl_trait:

pub trait Foo {
    fn foo() -> impl Sized;
}

impl Foo for () {
    fn foo() -> () {}
    //~^ WARN impl trait in impl method signature does not match trait method signature
    //~| NOTE add `#[allow(refining_impl_trait)]` if it is intended for this to be part of the public API of this crate
    //~| NOTE `#[warn(refining_impl_trait)]` on by default
    //~| HELP replace the return type so that it matches the trait
}

TC: We decided to make the first lint fire only when the trait is crate public. We did the same for the second lint but it was discussed less explicitly.

TC: tmandry proposes that we make the second lint always fire:

The async fn lint is only temporary to help avoid footguns created by missing language features, and we want to make non-footgunny uses more convenient.

Refinement is a mechanism that will always exist and is fundamental to trait implementations.

Refinement's ability to "punch through" abstraction boundaries can happen accidentally, even within a crate.

TC: CE has advocated to keeping it so that the lint only fires for publicly-reachable traits:

My understanding was that private traits are always crate-local, and be always fixed in a non-semver-breaking way, so it makes no sense to bug people about things local to their crate.

The refines lint being public-only has to do with the fact that refinement is a possibly-accidental over-promising of trait bounds on an implementation. when that implementation is published as part of a public (and reachable) trait in a library, then it becomes a breaking change to remove it. It doesn't make sense to enforce that internally within a crate, imo.

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?

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

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)

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.

TC: Where do we want to go from here?

"`.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 dependencies (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?

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

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

TC: We discussed this for most of one triage meeting in November without reaching any consensus. There is a design meeting proposal, but we have not yet scheduled it for a date. At Josh's suggestion, Ed Page has renominated this for us.

Earlier context included:

@scottmcm raised these interesting points:

My biggest question here is how much it should be thought of as tied to the script use, and thus to the #!.

My instinct is that either

This is tied to the shebang, so there's only one of them, to be consumed only by whatever tool is in the shebang, and rustc completely ignores it, like we completely ignore the shebang line. And thus the "``` right after the shebang" syntax seems entirely reasonable to me.

This is a general tool feature, for which there will be multiple of them, and for which they'd want something like tool attribute namespacing so there's a clear route to lots of them under understood namespaces, and are a full part of the parsed structure of the crate, maybe included in rustdoc, etc. (Like perhaps --document-private-items on a crate would show an embedded rustfmt::config block somewhere, one day.)

@nikomatsakis noted that, even if it's tied to a shebang, he doesn't see a reason to limit it to only one.

@tmandry suggested that:

With my lang hat on, I don't see a reason we should RFC a feature that only allows cargo front matter, without specifying a path to generalizing it to other tooling. If we want to be conservative in what we stabilize, let's approach that in the stabilization rather than in the RFC.

In the meeting, @nikomatsakis suggested that we seem misaligned on the purpose of this. Others in the meeting suggested that the syntax should derive from a clear understanding of that purpose and the eventual goals for it.

TC: We've since discussed this asynchronously here:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Syntax.20for.20embedded.20tooling.20metadata/near/409126434

We seemed to agree that:

.rs files should parse as valid Rust.
- I.e., we don't want to expect the runner to have to strip out these blocks.
Rust itself should not validate the content of these blocks.

The open questions include:

Should there be only one of these blocks or potentially many?
- If we only support one block, tools that need many will define their own syntax for delineation.
  - It could be awkward to change our mind later on this, as tools will have already defined this delineation in their own SemVer commitments.
- Supporting only one is simpler (for us) and gives tools flexibility.
- But if we want IDEs to eventually support syntax highlighting for these blocks (e.g. based on the file type indicated in the info string), then we probably need to handle this ourselves.
  - tmandry: "Making that kind of editor integration possible is important to me, even though I expect that many editors won't support that level of generality in their syntax definitions today."
Relatedly, do we want to support info strings?
Should the shebang be optional or required when using these blocks?
- It's more conventional for the shebang to be optional.
- If it's required, people may end up writing e.g. #!/bin/false as a workaround.
- The shebang is meaningless for Windows.
What syntax to use?
- Triple (or more) backticks.
  - Upside: Beginners may prefer this, but of course they would due to Markdown familiarity.
  - Downside: Even figuring out how to encode those backticks literally in this document is difficult. Users would need to know advanced Markdown to encode these Rust files. Some markdown parsers (e.g. the one for Discord) are not sophisticated enough to allow this.
    - tmandry: "I think that is a serious quality of life hazard we should be cognizant of. If I were to boil it down to a principle I would say that Rust should feel pleasant to use, and that includes in places like github comments, chatrooms, and forums, where many people write Rust code every day!"
  - Downside: It's a new matched string literal syntax when Rust already uses # for this.
- Triple (or more) hashes (###).
  - Upside: This would look natural with the shebang and would suggest association with the shebang.
  - Upside: Rust already uses matched #s for literals.
  - Downside: We may want a space before the info string.
- Triple (or more) dashes (---).
  - Upside/downside: This is associated with YAML header blocks.
  - Downside: It's a new matched string literal syntax when Rust already uses # for this.
  - Downside: This may look less natural with an info string, or we may want a space before it.

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

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

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

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