Triage meeting 2025-07-02

--- title: Triage meeting 2025-07-02 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-07-02 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-02/ url: https://hackmd.io/Cz4-mk1lQBiUljBo-CMBsA --- # T-lang meeting agenda - Meeting date: 2025-07-02 ## Attendance - People: TC, Santiago, Tyler Mandry, Taylor, Tomas Sedovic, Josh, scottmcm ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## Scheduled meetings - 2025-06-11: "Design meeting: Implementable trait aliases" [#322](https://github.com/rust-lang/lang-team/issues/322) - 2025-06-18: "Design meeting: "Marker effects"" [#317](https://github.com/rust-lang/lang-team/issues/317) - 2025-06-25: "Design meeting: Rust issues encountered by new Rust users in the Bevy project" [#229](https://github.com/rust-lang/lang-team/issues/229) - 2025-07-23: "Design meeting: Solution for `NoCell` and `no_std`" [#324](https://github.com/rust-lang/lang-team/issues/324) - 2025-07-30: "Design meeting: In-place Initialization" [#332](https://github.com/rust-lang/lang-team/issues/332) - Taylor will either write the doc or make sure that Alice will write the doc 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. ### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET TC: Remember that we have a design/planning meeting that starts half an hour after this call ends. ### Next meeting with RfL We're next meeting with RfL on 2025-07-02 to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Rust 2025 review ### Meta TC: We should start thinking about Rust 2025. Our motivating priorities are: - Make every edition a success. - Do so without requiring heroics from anyone. - ...or stressing anyone or everyone out. The tentative timeline will be: | Date | Version | Edition stage | |------------|---------------|--------------------------------| | 2025-04-03 | Release v1.86 | Checking off items... | | 2025-05-15 | Release v1.87 | Checking off items... | | 2025-06-26 | Release v1.88 | Checking off items... | | 2025-08-07 | Release v1.89 | Checking off items... | | 2025-09-12 | Branch v1.91 | Go / no go on all items | | 2025-09-18 | Release v1.90 | | | 2025-10-24 | Branch v1.92 | Stabilize Rust 2025 on nightly | | 2025-10-30 | Release v1.91 | Rust 2025 nightly beta | | 2025-12-05 | Branch v1.93 | Cut Rust 2025 to beta | | 2025-12-11 | Release v1.92 | Announce Rust 2025 is pending | | 2026-01-22 | Release v1.93 | Release Rust 2025 | None. ## Nominated RFCs, PRs, and issues ### "const-eval can construct uninhabited values via recursive static initialization" rust#143047 **Link:** https://github.com/rust-lang/rust/issues/143047 TC: Soundness issue. No PR yet, but there will need to be one. This is going to be a breaking change and the crater results are probably going to be bad. Josh: Where in normal code you'd be able to call things that take a `!` because you can't get a `!`, here you can get a `!` recursively from a function that gets a `!`. TC: theemathas posted this code sample: https://github.com/rust-lang/rust/issues/143047#issuecomment-3011650861 TC: The issue is not specific to `!`, and his example shows how you can get unsoundness at runtime. Tyler: Right now we're waiting on a fix? Josh: The runtime example is still using const evaluation and gets tripped by something that exists but shouldn't? Tyler: We were just talking about how static initializers can get a pointer to themselves. And this shows how it could actually create unsoundness. TC: Getting a reference, yes. Josh: Before I read this runtime example, I'd say "we'd just need to prohibit the never type". But that example is one where the type isn't uninhabited, but you shouldn't be able to create an instance violating the requirements... Tyler: Ralf said what I was thinking here. > Okay, so... the only actual solution I see here is to require such recursive self-references to go through raw pointers. So, this should just error: > > ```rust > static X: &Never = weird(&X); > ``` > > Instead, one has to write: > > ```rust > static X: &Never = weird(unsafe { &*&raw const X }); > ``` > > What this means implementation-wise is `&X` and `&mut XMUT` should fire the query for that static to ensure we are not forming a cycle. However, `&*&raw const X` should not fire the query, so this has to be a special syntactic hack I think. > > Also this is of course a breaking change, and I have no idea how big the fallout would be. > > Cc [@rust-lang/lang](https://github.com/orgs/rust-lang/teams/lang) for awareness. TC: I'll reply on the issue. ### "Experiment proposal: In-place initialization" lang-team#336 **Link:** https://github.com/rust-lang/lang-team/issues/336 TC: This is the one that we have the design meeting about. We have the separate work from Alice and Taylor here. There's some intersection between this and pin-ergonomics. Everyone should talk to each other about that. TC: We'll want a tracking issue about this if there's not one already. Josh: Excited to see the experiments here. And I'd like to explore and understand Taylor's idea as well. ### "RFC: Add an attribute for raising the alignment of various items" rfcs#3806 **Link:** https://github.com/rust-lang/rfcs/pull/3806 TC: We had finished FCP here, but we had missed something, so we'll be restarting the clock. Scott: There are some curious corners, but there were updates and we can talk about this during the partial stabilization. Alignment on functions that are not aligned feels weird. ### "Permit duplicate imports" rust#141043 **Link:** https://github.com/rust-lang/rust/pull/141043 TC: We had proposed FCP on this. TC: You can't currently import things that are the same by name. But the compiler does allow you to do that when the duplicates come in via glob imports. This proposal allows you to import two things that are the same when named explicitly too. TC: We had a discussion on this, including with obi1kenobi who works on semver checking. TC: I think the issues are the same as for glob imports. scottmcm: We have a specific semver carve-out for people who use glob imports -- they can be broken when using glob imports. scottmcm: Literally any addition to a crate can break when people are using glob imports. So we necessarily we have to communicate that this can break. Just because it behaves kind of like a glob doesn't automatically let me go: "oh okay". Josh: I agree we shouldn't be scope-creeping this to things other than macros. Did anyone find issues specificaly to duplicate imports of the same macro via a different path? TC: I don't have any appetite if we're just doing this for the macro namespace. This is already a nuanceed area; adding a carve-out for one namespace doesn't make sense to me and complicates the spec. Josh: That's a different point. What I was trying to ask is: the original ask was for macros -- has anyone found any additional issues there? TC: I don't think we found any additional issues. obi1kenobi is bringing up a concern e.g. with type aliases. Given where we're going with the treatment of those, this isn't an issue (as I replied on the issue, and with which he seemed to agree on that point). Josh: What were the acutal issues found with macros specifically? Tyler: There's nothing specific to macros, more general issues. Josh: The original version was just allowing this to allow macros imported via different path. TC: There are two threads here. There's what petrochenkov said, which is that this isn't creating any new problems, just expanding the degree to which people in the wild might rely on the existing things we're not entirely sure about. TC: Then there's the obi1kenobi angle about the semver stuff. Josh: There was also an item about different attributes on things. We can address by saying: "that's not the same thing, it's different attributes on the same thing". TC: Scott, back to your point about glob imports: I'm not sure this touches on our glob imports policy here. We're reducing SemVer breakage in many cases acording to the breakage theory. Scott: My statement wasn't about that. It was more about making a parallel to glob imports and that making it fine. It doesn't necessarily have to be semver fine. TC: In my view, everything we're talking about here can already be expressed today, just more indirectly. E.g.: https://github.com/rust-lang/rust/pull/141043#issuecomment-2920797415 TC: In my reading, RFC 1122 and 1105 already would not allow breaking this. Josh: We're at this point deep-diving solving the actual problem. I'd propose we cancel the current FCP that's proposing to do this for all items -- because we've not specified it clearly enough. And in the mean time let us iterate on this discussion async. TC: Fair enough. I'll cancel the FCP. Tyler: We could suggest a design meeting proposal as the next step. Josh: The only thing I said broken was "let's do this for everything without specifying it properly". Tyler: Okay, I agree with that. TC: I agree but I don't think this is specific to the expanded version only. Josh: We're in agreement that in this case it is under-specified. *everyone nods* ### "RFC: enable `derive(From)` for single-field structs" rfcs#3809 **Link:** https://github.com/rust-lang/rfcs/pull/3809 Scott: It's in FCP, all the Libs API people checked off on it. TC: Tyler you're the only checkbox left for the people who are here. Tyler: I had some concerns. One is the RFC being accepted and the other is, is this even a lang RFC? Tyler: It's only lang at the level of how people affect ?? Scott: I checked my box more from the "all of the feelings about it have been well expresesed in the thread". TC: That was similar to my checkbox. I think it's a lang matter to the degree that the core things like `From` derives affect the "flavor of the language", and it falls on us to make sure nothing crazy is happening. And I don't think it's too crazy or breaking the flavor of the language. Josh: I also question whether this is lang, but I understand. Scott: I don't think I'd accept this as a lang feature but as a library derive I think it's fine. ### "Consider folkertdev's `c_variadic` proposal" rust#141524 **Link:** https://github.com/rust-lang/rust/issues/141524 Josh: `c_variadic` was proposed for supporting cals to C language. @folkertdev has needs for this in zlib and is proposing a means of cleaning up this API so it can be easier to stabilize. This is simplifying the API to having just one type: `VaList`. It's efectively making it something closer to the C API with `va_copy` and similar. The proposal is: can we do something with this experiment and then stabilize it? Josh: The lang element: are we okay using super let in this macro. And second: are we confortable with this in any architecture? `va_end` is effectively a destructor. Can we rely on us committing to Scott: What are we being asked for here? Josh: https://github.com/rust-lang/rust/issues/141524#issuecomment-2994225710 Josh: Is it okay to designate `va_list ` and the other is not calling `va_end` UB? TC: I think this will require a design meeting/doc eventually, ahead of stabilization. Scott: I'm happy with experimenting and it seems at least surface-level plausible. Tyler: I agree with what Scott's saying and I don't have immediate concerns. Josh: Sounds like we're fine with unstable experiments happening in these areas and don't see any blockers with unstable experiments. If we were to consider going forward with stabilization we'll need a design meeting happening. TC: Agreed. The recurring challenges is that we're happy to see experimentation. But at the same same, we need to not lead people to believe that in approving the experiment that we've reviewed it carefully enough to be sure that we won't end up raising concerns later, even about what's written here, because we have not reviewed it that carefully. Josh: Got it. Scott: Might be good to say that if these questions are interesting for e.g. future platform support, an RFC update might be good. This is what the API would look like now. scott: here's the type they're mentioning in the comment: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/callconv/enum.PassMode.html ### "Permit attributes on `use` items" rust#141704 **Link:** https://github.com/rust-lang/rust/issues/141704 TC: The proposal is to allow attributes on use items. Deciding where to allow attributes is always tricky. Scott: It's certainly the case that if you have a CI requirement is if you have a bootstrap guard on something, you need to reformat it to another list or the CI fails. But for something more permanent like a feature I don't think it's such a win. Scott: I don't think I'm enthusiastic, but I don't think I'm saying no ??. Tyler: This also have style consideration. Scott: Is this all attributes or some attributes? I assume we can't put a proc macro here right now? Tyler: Do we allow proc-macro on a `use` directive today? TC: I think what's being asked of us here is to allow whatever we allow on `use` items. Tyler: We have a diagram in the Rererence now. Josh: I don't see a fundamental reason for why if we allow an attribute here we wouldn't allow a proc-macro (or in the future macro_rules) attribute. Scott: Which tokens does it get? Josh: I'd assume it'd get the tokens it's applied to. So in that case in the issue it'd get `gamma`, but in a more complex path you'd get the entry in the list (effectively everything before the comma). Josh: Do we allow attributes on ?? Scott: cfg attributes. Tyler: I don't think I'd go as far as allowing proc macros. TC: This isn't a PR; this is a vibes check. What do we want the next step to be? Josh: Seems like other than proc macros this seems appropriate. It would need someone to clearly specify how this would do that with proc macros. Scott+Tyler: I'd rather have a usecase for proc macro. Scott: I think the lint attributes and cfg have a motivation that seems plausible. Josh: There's a general argument for "anywhere we allow a general attribute we want to allow a proc-macro attribute". It makes sense we could create a proc-macro that would generate an attribute. TC: +1. TC: If this came in as a stabilization PR and a reference update, would we feel good about that or would it need the RFC? Tyler: I don't think it needs an RFC. Proc macro needs a motivating usecase or at least an argument for why it's specified is the correct behaviour. Josh: The vibe is: we're open to cfg and hint attributes and would need specification update. We're tentatively open to proc macros, but that requires a clear specification. (The first part of the meeting ended here.) --- (The second part of the meeting started here.) People: TC, tmandry, Tomas, Martin, Yosh, Nadri, Josh ### "Should a `[..]` slice pattern constitute a discriminant read" rust#141825 **Link:** https://github.com/rust-lang/rust/issues/141825 Tyler: I think we could choose either answer and be fine with it. I agree with Scott's point that it's easy to draw a parallel between `Struct { .. }` and `[..]`. Nadri: If I write unsafe code and I want to only check the discriminant, for enums I can write an or pattern, but ??. For slices I can write an or pattern too I guess (`[] | [_, ..]`). There's a difference between slices and structs. The discriminant of the enum is an extra piece of data. Tyler: `[..]` that can match against an empty slice, right? Nadri: Yes, they can match against any size. Tyler: All the cases are the same. Nadri: Same for range matches. `[..]` is kind of 0..=MAX on the length. TC: Would you count `[_ @ ..]` as a discriminant read also? Nadri: Yes, for the same reason as without the underscore. Josh: I don't know what currently happens with closure captures. But I retested and re-confirmed that if you have an unititialized struct, it will not complaint and it won't read the contents of the struct. I'd argue that's exactly analagous to "I'm looking at the entire slice but I'm not". TC: Except for a slice you have the wide pointer that has the extra bits of information. You have the object's value and the meta value. Nadri: For arrays I agree with you Josh. They're exactly the same as struct -- they have fixed length. Josh: In practice you don't have to read the link to see that the pattern checks nothing. Nadri: That's why I'm comparing it to rangies where 0..=MAX. That checks the integer. Josh: I'm not sure I'd treat that as an analagous situation. I'd treat it analagous to matching the `_` which doesn't read the contents of the integer. In this context, it needs to know it's a slice, it doesn't need to check anything. TC: Would you make that same argument for `0..=int::MAX`? Josh: in what contexct? Nadri: Matching an integer. Josh: ?? it should be a lint that sholud say this sholud be na underscore. TC: We've already decided in this case that it constitutes a read. Nadri: I propose the general rule that I wrote on the issue. TC: I agree with Nadri. I see the argument; it's consistent with what we've decided to do with the range patterns. The difference between this and the struct is the metadata piece where you're reading the length, and that's a critical distinction. Tyler: In the int range example, you can see the patterns and you immediately see that it's exhaustive. Nadri: Once we start going into the direction of negation patterns etc., we'll want to be consistent there also. Josh: Broadly, I agree with "nobody's going to notice". It really is a philosophical language definition and allow for potential future compatibility. If anyone would be using a closure and not wanting the capture, we could tell them that they should be using an underscore. I'd support a lint. Nadri: There is a counter argument: `[..]` will behave differently on an array. Yosh: C# has a really cool featire that allows you to implement pattern-matching sync on custom types. C# allows you to do things like pattern-match on VecDeque. That might be a design point to consider. We might have more than just two types in the future. Consistency might matter there. Tyler: I'm inclined to trust your instints if this is going to save us in the future. The primary downside is that it makes it trickier to write unsafe code. But we can always go back to saying it's not a read. TC: I think it's easier to write unsafe code because it makes for a clear model for it. Tyler: Not sure I agree with that; I think `[..]` being irrefutable is a clear model. But I think in this case, saving space for something we might plausibly want in the future is a better argument. Josh: To be clear, my comments earlier did not constitute an objection. I was communicating a preference that we should not do this, but if others want to do this then let's do it. Nadri: We could also have a lint. Josh: Given this is a change for future hypothetical work, if there's a downside (e.g. compilation slowdown) then we'd want to reconsider. (Wouldn't expect there to be, though.) Nadri: It's a one-line change. Don't expect there to be any impact. TC: There's no PR for this. Nadri I'm assuming you'll put up a PR, do a crater run and check the impact. Having a Reference update for this would be good as well. *Nadri will write up the discussion on the issue.* ### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198 **Link:** https://github.com/rust-lang/rust/pull/142198 TC: We were just talking about a minimum global alignment of functions. But here we're talking about an existing attribute on a target on minimum alignment of globals. Tyler: I don't think it's exposed as a target modifier. It specifies a target spec. Effectively we're just saying that on 3890x globals have a speficic alignment and we might do that for future platforms also. Tyler: I'm fine with doing this. TC: If we're making a language guarantee, I'd like to find some place in the Reference where we can document the language guarantee. Josh: This is also making me thing of: there's a similar thing on ARM that hase a bit of a quirk where using the lower bit on the address to differentiate between an arm vs. thumb assembly. Josh: They effectively require that arm entry points are align 2. That's already how it works, the question is: is that also a language guarantee? Tyler: This I think is for data which is fine. I'd propose trying to find a place in the reference to document it and then FCP that. TC: I'm not sure Scott(mcm) is fine with it based on reading the issue. TC: We'll have the same question on the minimum alignment for functions which we're encoding as a target modifier. I want to view it in that context -- if we're going to make a language guarantee for the function minimum alignment as a target modifier then this one makes sense too. (scottmcm joins us at this point.) Tyler: Bringing in the other issue where we discussed the cache, there was a question whether it's a language guarantee or compiler correctness. Josh: Feels this is more a target guarantee that the language is simply propagating. This is a property of the target that we're propagating so people can continue to rely on that. If a target decided to drop the guarantee, it wouldn't be a lang matter. Just that we're passing it throught whatever it is. Tyler: This issue is framed as const eval. If we do const-eval do we apply the minimum alignment. In order to effectively implement the minimum alignment we'd have to do that. But there are variables that don't end up in the final binary at all -- and for those we have the option on not applying the minimum alignment. I guess that's where the language question comes in. Scott: What is the actual problem? Is it that LLVM is emitting code for how something was actually defined? That feels like LLVM bug. So I don' think that's a justification for doing that. But if there's a "every static must be aligned to at least 2 ABI rule", then I guess we just have to do that and reflecting that in `static`s makes sense? Tyler: This is a compiler correctness issue. But I don't see why it needs to be a language-level guarantee at this point. TC: Isn't that the same though, if you're modelling the language abstractly? Scott: We can run the const-eval with "it's an alignment of at least 1" then targets can specify higher alignment, but we're not making a lang guarantee. TC: There's a question about what inline assembly can rely on. Tyler: Inline assembly goes outside the language level guarantee. TC: Do we want to ask on the thread for an analysis of to what degree they might be asking for a language-level guarantee that goes beyond what one would consider to be a correct compiler-level implementation? Tyler: I'd say the compiler would be correct to place global allocations that are required on the target. That's different than saying that in const-eval every single global will have the same alignment. TC: To what degree would we apply this same analysis to the function minimum alignment behavior with the target modifier? Scott: I'd hope that everything called a target modifier works the same as setting the target value in the conf file. Scott: We say, in Rust the function doesn't have a specific alignment. But Rust puts the functions for which alignment it doesn't care according to the target. It's a target property not Rust property. Tyler: Can you depend in Rust code on the address of a stack being aligned when you consider it on a target that requires that? I think the answer is yes (if it's stable and documented for that target). Scott: Using C++ standard terminology, I'd call this an implementation-level behaviour. Tyler: On the one hand it makes sense. But if there's only one implementation to rely on TC: In Rust we have a much more limited concept of implementation-defined behavior because we own the implementation. Scott: That's not spec-writing question though. Scott: Analogy: we have a bunch of ABIs where certain kinds of values are passed in the stack as function parameters. I don't think we'd make a language-level guarantee that Rust would have the functions parameters aligned, ??. The compiler would always put it at that address, but the Rust abstract machine wouldn't specify the address. TC: So you couldn't rely on it in Rust code, you're saying. Tyler: Another question is: why would all globals be aligned on s390x 2? There's a `larl` function that requres it, but it's not the target expectation. Scott: Agreed, it's unclear to me to what level this is a target expectation or implementation choice. Was there a "here's the link to the target ABI that says this" or just "well LLVM has a bug that it breaks if you have globals with less alignment"? TC: We have enough feedback to comment on this feature. We should probably leave our individual thoughts here. ### "Warn or error on duplicate attributes" rust#142836 **Link:** https://github.com/rust-lang/rust/issues/142836 TC: There are a lot of edge cases here on attributes. Eric Huss recently put in dozens of Reference PRs to fully and consistently document these. Josh: Can we come up with a policy or is this going to be attribute-dependent? We can come up with a general policy that says e.g. it should always be at least a `warn` and a message saying what you should do. But that's only going to be a broad guideline. There are things like `repr` where they don't conflict but stack. And `inline` where multiples are always in conflict. TC: I think for the cases like `repr` you have to go down a level. Because if you have `repr(align(8))` and `repr(align(16))` you're in the same situation as inline. Scott: I wonder if we could at least have a policy where we prefer warnings for duplicates. Any conflicts must be an error. But for the example of `deprecated` -- it doesn't really have semantics anyway. So is it really a conflict? Or do we just give warning saying that they're different but we're probably going to be picking one anyway. The nice thing about warnings is that we don't have to write a spec about this. Tyler: I'm align with warning on this. I'm also being more permissive on e.g. picking the highest value an duplicated `repr`. Josh: We should define a premise of: if two things are redundant but don't require anything to fix, we can show a warning. If things semantically conflict, it should be an error. And then we can allow the attributes to specify what's redundant, what stacks and what's a semantic conflict. We should define that at the language level. Josh: I'd argue we should err on the side of erroring where we could. scottmcm: I would say they very much conflict, because they change layout. tmandry: good point scott – I was actually thinking about `#[align]`. TC: My propsal is we agree to warn on all that are questionable or worse. And then take further steps along the lines of what Josh proposed. Josh: Sounds reasonable to me. I would be happy to write up a summary. Josh: Are there any cases there's a silent acceptance where we want to be a warning? TC: I'd suggest we might want to go further on the duplicates. Josh: So documenting the three categories and broadly speaking what we might want. TC: Right, and saying that we "at least" want to warn on these. We might want to go further in some cases. Tyler: Are we picking an warn or error on duplicate attributes? Josh: We're not making a hard decision on every given attribute. We're deciding on what we want to do in general. This is more of a vibe check of the PR we want to be checking on. Tyler: I was hoping we'd have an agreement that we wouldn't do more than warn on attributes that are duplicate. Is there anything actionable that comes from such a limited decision? Tyler: Looks like we don't warn on this today: ```rust #[repr(C)] #[repr(C)] struct Foo; ``` Tyler: I wouldn't want these cases to be an error. Josh+TC: We want to clarify what we want to do without upper-bounding the decision (warning vs. error). TC: I think the vibe is we want to clean these up and we want to see case-by-case PRs. And we want to do this stepwise; we won't hard-error on anything right away. Tyler: I'd be fine with an initial PR that moves _all_ attributes that don't warn on duplicates to warn on duplicates. Going farther than that should be case-by-case. ### "&str and &[u8] have the same layout" reference#1848 **Link:** https://github.com/rust-lang/reference/pull/1848 Josh: We already guarantee that `str` and `[u8]` guarantee to have the same layout. This is just extending it to `&str` and `&[u8]`. I think that sounds reasonable and we should accept that. Tyler: I'd love to see this in the Reference. Tyler: My only concern would be if this limits us from doing something like if you have a String argument and you supply a string literal somehow making that work. i.e. making this compile: ```rust fn foo(x: String){} fn main() {foo("asdf")} ``` Tyler: I remember there being discussion around having a "string literal type" that coerces or similar. But by the time you know you have an `&str` it should be fine to make this guarantee. Josh: I don't think this prevents from doing something with `String`. I think the main reason is being able to transmute `&str` and `&[u8]`, transmuting a struct with such etc. TC: Do we need to make a guarantee at the ABI layout? Josh: That's an interesting question. This is just a memory layout guarantee. If you wanted to have one accept the other, that would need to be a separate PR. Josh: +1 for giving the guidance of "this doesn't specify the ABI compatibility of the two". We should reference Ralf's point (in standard library speficication for functions). Tyler: Do we want to extend this to ABI? Josh: We'd have to check with the wasm folks and any work on the future target. Tyler: I agree with this. Tyler: Just confirming this doesn't have any bearing on the layout of Cstr. Josh: No it doesn't. I'll start the FCP. ### "Decide on behavior of `anonymous_lifetime_in_impl_trait`" rust#137575 **Link:** https://github.com/rust-lang/rust/issues/137575 TC: This one is going to need Niko. ### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251 **Link:** https://github.com/rust-lang/lang-team/issues/251 Josh: This is a vibe check. In the context of libs having a compile-time assert. What if you have a const block and write assert on that -- then you'd have a const-time assert. Josh: There was discussion in this issue about how there's a difference between `const _ ` vs. `const { .. }` one is pre-mono and the other is post-mono. Josh: From a vibes perspective it's a easy to specify this at the top level and function context. It's really hard to specify this inside of an impl block. Tyler: The reason it's difficult to specify in the impl block, you'll only get the evaluation happening after you monomorphize with the ?? Tyler: In terms of vibes, I'm happy with this. It's easier to write top-level const rather than `const _: () = ...` TC: It is something of a break from our prior practices in the language, given that we make a sharp distinction between item and expression contexts. This provides a kind of top-level expression context. I'm not saying that's bad, just that it's big in that way. Tyler: I'm still inclined moving forward, but I'll consider any ramifications. TC: So basically this is just eliding the `_: () =` part from the top-level example? Josh: Yes and the error message can be better. Other than that I'd consider them to be semantically equivalent. TC: I like it. (The meeting ended here.) --- ### "`fn_cast!` macro" rust#140803 **Link:** https://github.com/rust-lang/rust/issues/140803 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ### "Decision: Use the condition name `rust_version` for RFC 2523" rust#142651 **Link:** https://github.com/rust-lang/rust/issues/142651 ### "Stabilize `-Cmin-function-alignment`" rust#142824 **Link:** https://github.com/rust-lang/rust/pull/142824 ### "Rename "unsized" coercion as "unsizing"" reference#1797 **Link:** https://github.com/rust-lang/reference/pull/1797 ## On radar RFCs, PRs, and issues ### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087 **Link:** https://github.com/rust-lang/rust/pull/139087 ### "[WIP] Forbid object lifetime changing pointer casts" rust#136776 **Link:** https://github.com/rust-lang/rust/pull/136776 ### "Tracking issue for `cfg_select` (formerly `cfg_match`)" rust#115585 **Link:** https://github.com/rust-lang/rust/issues/115585 ### "Split elided_lifetime_in_paths into finer-grained lints" rust#120808 **Link:** https://github.com/rust-lang/rust/pull/120808 ### "Arbitrary self types v2: stabilize" rust#135881 **Link:** https://github.com/rust-lang/rust/pull/135881 ### "Stabilize return type notation (RFC 3654)" rust#138424 **Link:** https://github.com/rust-lang/rust/pull/138424 ### "`#[target_feature]` mismatch on unsafe trait fn vs its impl causes sneaky UB" rust#139368 **Link:** https://github.com/rust-lang/rust/issues/139368 ### "Spurious irrefutable_let_patterns warning with let-chain" rust#139369 **Link:** https://github.com/rust-lang/rust/issues/139369 ### "Stabilize `fn_align`: `#[align(N)]` on functions" rust#140261 **Link:** https://github.com/rust-lang/rust/pull/140261 ### "`core::marker::NoCell` in bounds (previously known an `Freeze`)" rfcs#3633 **Link:** https://github.com/rust-lang/rfcs/pull/3633 ### "Unsafe derives and attributes" rfcs#3715 **Link:** https://github.com/rust-lang/rfcs/pull/3715 ### "[RFC] Allow packed types to transitively contain aligned types" rfcs#3718 **Link:** https://github.com/rust-lang/rfcs/pull/3718 ### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796 **Link:** https://github.com/rust-lang/rust/issues/64796 ### "Support for pointers with asm_const" rust#128464 **Link:** https://github.com/rust-lang/rust/issues/128464 ### "lexer: Treat more floats with empty exponent as valid tokens" rust#131656 **Link:** https://github.com/rust-lang/rust/pull/131656 ### "An unsafe const fn being used to compute an array length or const generic is incorrectly described as being an "item"." rust#133441 **Link:** https://github.com/rust-lang/rust/issues/133441 ### "Stabilize `derive(CoercePointee)`" rust#133820 **Link:** https://github.com/rust-lang/rust/pull/133820 ### "experiment with relaxing the orphan rule" rust#136979 **Link:** https://github.com/rust-lang/rust/issues/136979 ### "Tracking issue for unsupported_calling_conventions" rust#137018 **Link:** https://github.com/rust-lang/rust/issues/137018 ### "Oddity with lifetime elision and type aliases" rust#140611 **Link:** https://github.com/rust-lang/rust/issues/140611 ### "Split up the `unknown_or_malformed_diagnostic_attributes` lint" rust#140717 **Link:** https://github.com/rust-lang/rust/pull/140717 ### "Add `core::ptr::assume_moved`" rfcs#3700 **Link:** https://github.com/rust-lang/rfcs/pull/3700 ### "RFC: Add an attribute for raising the alignment of various items" rfcs#3806 **Link:** https://github.com/rust-lang/rfcs/pull/3806 ### "#[deprecated] lint doesn't trigger when overriding deprecated method" rust#98990 **Link:** https://github.com/rust-lang/rust/issues/98990 ### "Tracking Issue for unicode and escape codes in literals" rust#116907 **Link:** https://github.com/rust-lang/rust/issues/116907 ### "sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617 **Link:** https://github.com/rust-lang/rust/pull/123617 ### "Built-in attributes are treated differently vs prelude attributes, unstable built-in attributes can name-collide with stable macro, and built-in attributes can break back-compat" rust#134963 **Link:** https://github.com/rust-lang/rust/issues/134963 ### "Add checking for unnecessary delims in closure body" rust#136906 **Link:** https://github.com/rust-lang/rust/pull/136906 ### "Consider folkertdev's `c_variadic` proposal" rust#141524 **Link:** https://github.com/rust-lang/rust/issues/141524 ### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641 **Link:** https://github.com/rust-lang/rfcs/pull/3641 ### "RFC: No (opsem) Magic Boxes" rfcs#3712 **Link:** https://github.com/rust-lang/rfcs/pull/3712 ### "Tracking Issue: Procedural Macro Diagnostics (RFC 1566)" rust#54140 **Link:** https://github.com/rust-lang/rust/issues/54140 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "Remove unstable cfg `target(...)` compact feature" rust#130780 **Link:** https://github.com/rust-lang/rust/pull/130780 ### "Strengthen the follow-set rule for macros" rust#131025 **Link:** https://github.com/rust-lang/rust/issues/131025 ### "Warn about C-style octal literals" rust#131309 **Link:** https://github.com/rust-lang/rust/pull/131309 ### "Add lint against (some) interior mutable consts" rust#132146 **Link:** https://github.com/rust-lang/rust/pull/132146 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "RFC: Improved State Machine Codegen" rfcs#3720 **Link:** https://github.com/rust-lang/rfcs/pull/3720 ### "Add `must-use-output` attribute" rfcs#3773 **Link:** https://github.com/rust-lang/rfcs/pull/3773 ### "Effective breakage to `jiff` due to `ambiguous_negative_literals`" rust#128287 **Link:** https://github.com/rust-lang/rust/issues/128287 ### "Simplify lightweight clones, including into closures and async blocks" rfcs#3680 **Link:** https://github.com/rust-lang/rfcs/pull/3680 ### "Declarative `macro_rules!` attribute macros" rfcs#3697 **Link:** https://github.com/rust-lang/rfcs/pull/3697 ### "Declarative `macro_rules!` derive macros" rfcs#3698 **Link:** https://github.com/rust-lang/rfcs/pull/3698 ### "Macro fragment fields" rfcs#3714 **Link:** https://github.com/rust-lang/rfcs/pull/3714 ### "Add `homogeneous_try_blocks` RFC" rfcs#3721 **Link:** https://github.com/rust-lang/rfcs/pull/3721 ### "Elided lifetime changes in `rust_2018_idioms` lint is very noisy and results in dramatically degraded APIs for Bevy" rust#131725 **Link:** https://github.com/rust-lang/rust/issues/131725 ### "Coercing &mut to *const should not create a shared reference" rust#56604 **Link:** https://github.com/rust-lang/rust/issues/56604 ### "#[cold] on match arms" rust#120193 **Link:** https://github.com/rust-lang/rust/pull/120193 ### "`is` operator for pattern-matching and binding" rfcs#3573 **Link:** https://github.com/rust-lang/rfcs/pull/3573 ### "Unsafe fields" rfcs#3458 **Link:** https://github.com/rust-lang/rfcs/pull/3458 ### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556 **Link:** https://github.com/rust-lang/rfcs/pull/3556 ### "Hierarchy of Sized traits" rfcs#3729 **Link:** https://github.com/rust-lang/rfcs/pull/3729 ### "Language vs. implementation threat models and implications for TypeId collision resistance" rust#129030 **Link:** https://github.com/rust-lang/rust/issues/129030 ### "RFC: inherent trait implementation" rfcs#2375 **Link:** https://github.com/rust-lang/rfcs/pull/2375 ### "Raw Keywords" rfcs#3098 **Link:** https://github.com/rust-lang/rfcs/pull/3098 ### "RFC: Implementable trait aliases" rfcs#3437 **Link:** https://github.com/rust-lang/rfcs/pull/3437 ### "Should Rust still ignore SIGPIPE by default?" rust#62569 **Link:** https://github.com/rust-lang/rust/issues/62569 ### "types team / lang team interaction" rust#116557 **Link:** https://github.com/rust-lang/rust/issues/116557 ### "Trait method impl restrictions" rfcs#3678 **Link:** https://github.com/rust-lang/rfcs/pull/3678 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418 **Link:** https://github.com/rust-lang/rust/pull/106418 ### "Fallout from expansion of redundant import checking" rust#121708 **Link:** https://github.com/rust-lang/rust/issues/121708 ### "What are the guarantees around which constants (and callees) in a function get monomorphized?" rust#122301 **Link:** https://github.com/rust-lang/rust/issues/122301 ### "Policy for lint expansions" rust#122759 **Link:** https://github.com/rust-lang/rust/issues/122759 ### "Decide on path forward for attributes on expressions" rust#127436 **Link:** https://github.com/rust-lang/rust/issues/127436 ### "`continue` expressions in loop conditions" rust#118673 **Link:** https://github.com/rust-lang/rust/issues/118673 ### "Tracking Issue for `breakpoint` feature (`core::arch::breakpoint`)" rust#133724 **Link:** https://github.com/rust-lang/rust/issues/133724 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "RFC: Allow type inference for const or static" rfcs#3546 **Link:** https://github.com/rust-lang/rfcs/pull/3546 ### "RFC: Unsafe Set Enum Discriminants" rfcs#3727 **Link:** https://github.com/rust-lang/rfcs/pull/3727 ### "RFC: naming groups of configuration with `cfg_alias`" rfcs#3804 **Link:** https://github.com/rust-lang/rfcs/pull/3804 ### "de-RFC: Remove unsized_locals" rfcs#3829 **Link:** https://github.com/rust-lang/rfcs/pull/3829 ### "Decide what we want about `macro_metavar_expr`" rust#137581 **Link:** https://github.com/rust-lang/rust/issues/137581 ### "Original `pin!()` macro behavior cannot be expressed in Rust 2024" rust#138718 **Link:** https://github.com/rust-lang/rust/issues/138718 ### "Allow while let chains on all editions" rust#140204 **Link:** https://github.com/rust-lang/rust/pull/140204 ### "Lang proposal: Allow `#[cfg(...)]` within `asm!`" rust#140279 **Link:** https://github.com/rust-lang/rust/issues/140279 ### "Stabilize `#[cfg(version(...))]`, take 2" rust#141766 **Link:** https://github.com/rust-lang/rust/pull/141766 ### "A path towards erroring on nonsense attributes" rust#142838 **Link:** https://github.com/rust-lang/rust/issues/142838 ## Action item review - [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## Pending lang team project proposals None. ## PRs on the lang-team repo ### "Frequently requested changes: add bypassing visibility" lang-team#323 **Link:** https://github.com/rust-lang/lang-team/pull/323 ### "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 ### "Update hackmd link to a public link" lang-team#258 **Link:** https://github.com/rust-lang/lang-team/pull/258 ### "Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267 **Link:** https://github.com/rust-lang/lang-team/pull/267 ### "text describing how other teams are enabled to make decisions." lang-team#290 **Link:** https://github.com/rust-lang/lang-team/pull/290 ### "Fix link to agenda template" lang-team#315 **Link:** https://github.com/rust-lang/lang-team/pull/315 ### "new decision process" lang-team#326 **Link:** https://github.com/rust-lang/lang-team/pull/326 ### "Clarify that taking input in coroutines currently uses 'yield expressions'" lang-team#328 **Link:** https://github.com/rust-lang/lang-team/pull/328 ### "Document experimental `P-lang-drag-[0-4]` and `I-lang-easy-decision`" lang-team#330 **Link:** https://github.com/rust-lang/lang-team/pull/330 ## RFCs waiting to be merged ### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641 **Link:** https://github.com/rust-lang/rfcs/pull/3641 ### "Declarative `macro_rules!` attribute macros" rfcs#3697 **Link:** https://github.com/rust-lang/rfcs/pull/3697 ### "Declarative `macro_rules!` derive macros" rfcs#3698 **Link:** https://github.com/rust-lang/rfcs/pull/3698 ## `S-waiting-on-team` ### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087 **Link:** https://github.com/rust-lang/rust/pull/139087 ### "Stabilize `fn_align`: `#[align(N)]` on functions" rust#140261 **Link:** https://github.com/rust-lang/rust/pull/140261 ### "lexer: Treat more floats with empty exponent as valid tokens" rust#131656 **Link:** https://github.com/rust-lang/rust/pull/131656 ### "Permit duplicate imports" rust#141043 **Link:** https://github.com/rust-lang/rust/pull/141043 ### "`repr(tag = ...)` for type aliases" rfcs#3659 **Link:** https://github.com/rust-lang/rfcs/pull/3659 ### "Remove unstable cfg `target(...)` compact feature" rust#130780 **Link:** https://github.com/rust-lang/rust/pull/130780 ### "Add lint against (some) interior mutable consts" rust#132146 **Link:** https://github.com/rust-lang/rust/pull/132146 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "Stabilize `-Cmin-function-alignment`" rust#142824 **Link:** https://github.com/rust-lang/rust/pull/142824 ### "#[cold] on match arms" rust#120193 **Link:** https://github.com/rust-lang/rust/pull/120193 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "Permissions" rfcs#3380 **Link:** https://github.com/rust-lang/rfcs/pull/3380 ### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550 **Link:** https://github.com/rust-lang/rust/pull/119550 ### "Tracking Issue for `bare_link_kind`" rust#132061 **Link:** https://github.com/rust-lang/rust/issues/132061 ### "Add compiler support for namespaced crates" rust#140271 **Link:** https://github.com/rust-lang/rust/pull/140271 ## Proposed FCPs **Check your boxes!** ### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087 **Link:** https://github.com/rust-lang/rust/pull/139087 ### "Arbitrary self types v2: stabilize" rust#135881 **Link:** https://github.com/rust-lang/rust/pull/135881 ### "Stabilize return type notation (RFC 3654)" rust#138424 **Link:** https://github.com/rust-lang/rust/pull/138424 ### "`core::marker::NoCell` in bounds (previously known an `Freeze`)" rfcs#3633 **Link:** https://github.com/rust-lang/rfcs/pull/3633 ### "Unsafe derives and attributes" rfcs#3715 **Link:** https://github.com/rust-lang/rfcs/pull/3715 ### "RFC: Add an attribute for raising the alignment of various items" rfcs#3806 **Link:** https://github.com/rust-lang/rfcs/pull/3806 ### "sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617 **Link:** https://github.com/rust-lang/rust/pull/123617 ### "Add checking for unnecessary delims in closure body" rust#136906 **Link:** https://github.com/rust-lang/rust/pull/136906 ### "Permit duplicate imports" rust#141043 **Link:** https://github.com/rust-lang/rust/pull/141043 ### "RFC: No (opsem) Magic Boxes" rfcs#3712 **Link:** https://github.com/rust-lang/rfcs/pull/3712 ### "Remove unstable cfg `target(...)` compact feature" rust#130780 **Link:** https://github.com/rust-lang/rust/pull/130780 ### "Warn about C-style octal literals" rust#131309 **Link:** https://github.com/rust-lang/rust/pull/131309 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ### "Decision: Use the condition name `rust_version` for RFC 2523" rust#142651 **Link:** https://github.com/rust-lang/rust/issues/142651 ### "Unsafe fields" rfcs#3458 **Link:** https://github.com/rust-lang/rfcs/pull/3458 ### "[RFC] externally implementable functions" rfcs#3632 **Link:** https://github.com/rust-lang/rfcs/pull/3632 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418 **Link:** https://github.com/rust-lang/rust/pull/106418 ### "Policy for lint expansions" rust#122759 **Link:** https://github.com/rust-lang/rust/issues/122759 ### "Decide on path forward for attributes on expressions" rust#127436 **Link:** https://github.com/rust-lang/rust/issues/127436 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "RFC: Allow type inference for const or static" rfcs#3546 **Link:** https://github.com/rust-lang/rfcs/pull/3546 ### "Allow `&&`, `||`, and `!` in `cfg`" rfcs#3796 **Link:** https://github.com/rust-lang/rfcs/pull/3796 ### "de-RFC: Remove unsized_locals" rfcs#3829 **Link:** https://github.com/rust-lang/rfcs/pull/3829 ### "Stabilize associated type position impl Trait (ATPIT)" rust#120700 **Link:** https://github.com/rust-lang/rust/pull/120700 ### "Allow while let chains on all editions" rust#140204 **Link:** https://github.com/rust-lang/rust/pull/140204 ### "Stabilize `#[cfg(version(...))]`, take 2" rust#141766 **Link:** https://github.com/rust-lang/rust/pull/141766 ### "new decision process" lang-team#326 **Link:** https://github.com/rust-lang/lang-team/pull/326 ## Active FCPs ### "RFC: enable `derive(From)` for single-field structs" rfcs#3809 **Link:** https://github.com/rust-lang/rfcs/pull/3809 ## P-critical issues None.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.