Lang/RfL meeting 2025-07-02

--- title: "Lang/RfL meeting 2025-07-02" tags: ["T-lang", "design-meeting", "minutes"] date: 2025-07-02 discussion: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025-07-02.20meeting/ url: https://hackmd.io/HaZ3LP_CRFmY1rLmqQJ-Tg --- # Lang/RfL meeting 2025-07-02 ## Attendance People: Benno Lossin, David Wood, Gary Guo, Josh Triplett, Miguel Ojeda, Ramon de C Valle, TC, Tyler Mandry, Wesley Wiser, Boqun Feng ## Tracking [Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116) ## Stabilize `derive(CoercePointee)` (blocked on #136764 / #136776) The stabilization is: https://github.com/rust-lang/rust/pull/133820 Finished FCP, waiting on author. Needs to resolve conflicts. This is on Ding. ## Stabilize arbitrary self types v2 (blocked on #136764 / #136776) TC: Blocked on us on the lang side. Need to figure out what we're going to do with implementable trait aliases, implementing supertraits from subtrait impls, etc. Taylor wrote the doc on this for the recent lang meeting. TC: I think Ding was working on an experimental implementation. Miguel: Ding had an update from 25th June. Tomas to reach out to Ding and ask about the update. (post-meeting update from Ding: "I wish that I could have done more. At the moment I am still trying small things in the name resolution and I need more time. I don't have something concretely working at the moment.") Tyler: If he needs a point of contact for arbitrary self types and supertrait stuff I'll be happy to volunteer. ## support for pointers with asm_const https://github.com/rust-lang/rust/issues/128464 TC: Someone needs to write up an RFC. Tyler: Why is this complicated enough to need an RFC? TC: It's because all the things brought up in the thread: which keyword we want to use, the details of the expansion, etc. Sarah brought up something. We talked about this in the lang meeting and it got long and complicated. We wanted someone to write it all down. Tomas to ask Alice (Ryhl). Miguel: from previous minutes: Gary maybe will rebase. ## Target modifiers (draft PR from @azhogin) https://github.com/rust-lang/rust/pull/138736 Needs a rebase. https://github.com/rust-lang/rust/pull/136597 ## `-Zindirect-branch-cs-prefix` Not really a target modifier, but is on top of the retpoline ones. Miguel: waiting for review. Miguel: It adds the "cs" prefix. It's used together with the retpoline ones. Josh: Is there ever a case where you'd use retpoline and not this? Miguel: Currently, no. We only use it on intel and the flag is enabled at the same time as retpoline. Josh: Should this need a separate flag or can this be enabled every time retpoline is on? Miguel: Not sure -- it is used to increase the instruction length so that more places can inline the `lfence`. Perhaps other kernels want retpoline but do not want that. Josh: We shouldn't expose a combination of options no one needs. If this is essentially a bug fix we should just treat it like that. Miguel: But if we later need to do this. Josh: If hypothetically we need to change this feature I'd suggest to provide arguments to the `retpoline` flag. Rather than having multiple independent flags. Miguel: I'll check. Tyler: Is retpoline a target modifier? Miguel: We'll treat it as a global target feature (i.e. a target modifier for which UB does not matter but typically you want to use it for all your translation units). The `-Cmin-function-alignment` one will also be another such case. Ramon: For some mitigations if you omit the flag when omitting the compilation unit, you don't apply it and result in a partially vulnerable binary. It's good for people building mixed-language binaries to have the flags named consistently between compilers. It's easier to use and check. For mitigations it's important to see that it's applied consistently. Miguel: Could this be done in the debug information -- annotate the object in the comment section with the mitigations enabled? Ramon: I think it makes sense but it'd require coordination between different compilers. Miguel: Sometimes if Rust does something that's inconsistent with Clang or GCC we'll need to handle it specially (e.g. have one `Makefile` line for one but not the other(s)). Tyler: I'd say in cases when we could choose to be consistent with other compilers and aren't paying much for that consistency then we should. Miguel: By the way for the "cs" prefix flag, ?? Josh: This is not actually about increasing the mitigation, it's about turning it into something larger so it can be replaced at runtime. In that case it pretty definitevly you don't want this without retpoline. But you absolutely might want to have retpoline without this. I personally think that having this as a modifier on retpoline might make more sense. Miguel: For us it's easier to have it independent. Tyler: It's ultimately a compiler question. We'll spell the options and let the compiler people to decide. https://github.com/rust-lang/rust/pull/140740 # Ding's Report Good evening, this is Wednesday report for current projects. ## `(p)init` I have largely sorted out the *HIR* type-checking. To verify the results, I have moved onto working in the frontend AST for quick smoky tests. In this iteration, I will introduce only `init [ $e1, $e2, $e3, ... ]`, in other words the array initialization support. The patch is scheduled for publishing by end of the week. What would not be included in this patch is MIR building and, of course, eventual codegen. I will post the PR when it goes live. ## `arbitrary_self_type` Work started again. Here we are talking about `impl Subtrait` with supertrait items. The first patch, also scheduled this week, would only concerns the name resolver. I have reached out to Vadim on his opinion on introducing extra crate metadata to support cross-crate supertrait information. The patch would tentatively be based on this mechanism for cross-crate supertrait support. ## `The ASM challenge` The PR is merged! I don't have enough bandwidth for this week, but you can expect more activity on this section. I am looking forward to posting some PRs here! ## Ramon's topics Ramon: Any concerns with the PRs that stabilize the AddressSanitizer and LeakSanitizer? https://github.com/rust-lang/rust/pull/123617 https://github.com/rust-lang/rust/pull/142681 Ramon: We've created these as two separate PRs. How should they be merged? There are going to be sequence of commits where the sanitizer attributes will be stable and the ?? Tyler: Has that attribute been RFCd before? Ramon: My assumption was that it was FCPd in the stabilization of the sanitizer. Tyler: I see, looks like I've missed the lang discussion about the attribute. I think including it in the stabilization is fine if there aren't tricky questions there. If tere are we may want to split it out so we can stabilize a part of it. Ramon: I tried to cover this in the docs but let me know if I should make this clearer. I think we only support this for LLVM the compiler was built with. Josh: The only other thing coming to mind: if you're using about six different ones to spell out all the different `a=off,b=off,c=off` etc. vs. something like `all=off`. Ramon: The idea was to add some flexibility between just `on` / `off`. Josh: Sure! But I can easily imagine people may want to just say "I want all of them off". I still think this is the right approach. Ramon: I typically only see people only disabling some (e.g. CFI or just kernel) sanitizers. I haven't seen people doing lots of them together. Tyler: There are some sanitizers that it would be UB to just disable them for specific functions. Tyler: I'm reading some comments from two weeks ago we might want to split out the attributes ?? TC: I think they pulled the attribute off of the stabilization there. There's a PR that uses the attribute syntax that's much more likely to be what we want. Tyler: Does anybody want to stabilize them together? Ramon: I'd be in favour of doing them together so people have the granularity on stable. Tyler: Do we have precedent for "on/off" strings compared to true/false? Josh: There's no type specification for attribute values. We could support false here and then allowing a string or curly braces and some specifics in the future. Tyler: Are there examples of options we can already think of where we'd want more than true/false? TC: It's pretty easy to see how this could be. E.g. LTO ended up being "thin", "fat", etc. Josh: I can imagine having options for that. This is more a question the consistency with what we're doing. There's some value of saying it's boolean so it's a bool value (true/false). Tyler: In compiler we actually use "yes"/"no". Ramon: "on"/"off" seems intuitive to me as we're enabling/disabling the sanitizers. In clang the same is true. But I could see in the Rust compiler this being a mode e.g. CFI being "permisive". Tyler: In the rustc book we say compiler flags we accept yes/no, on/off, true/false: https://doc.rust-lang.org/beta/rustc/codegen-options/index.html Tyler: No strong opinion here. I'd check for consistency with the existing attributes in the language. Josh: Mild preference for doing the boolean but I'd probabyl check the box either way. When we give an error, we should give you a rustfix saying the correct value. Tyler: I would also want to include consideration of consistency with other attributes. I'd check a box pretty much regardless, but capturing some of our thinking and what we considered is important. ## 2025H2 goals https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/2025H2.20goals/near/525160145 Miguel: I wrote a summary of the goals we'd like to do. Tomas: Having a goal per PR or per flag is a bit too granular. Josh: A good grouping would be a goal for all the target modifiers. Tomas: Which teams may be involved? Miguel: Teams involved are language, library, compiler, `rustdoc`, Clippy, opsem... ## `Alignment` vs. `PowerOfTwo<T>` https://lore.kernel.org/rust-for-linux/CANiq72=BSnom-nQgzLvv-cqwSknK1uJ=CXGP51r0WRj1Y553Ew@mail.gmail.com/ Miguel: There is a unstable Alignment type in the standard library -- we could use that on stable, especially if generic. Or better yet having a PowerOfTwo type. ## Mentoring rperier would like to be mentored/work on Rust compiler tasks related to Rust for Linux: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Rust4linux.20and.20the.20compiler/near/526768028 Miguel: If there's any task on the compiler that would be doable where there would be a mentor available, that'd be great. ## Google Meet chat Miguel Ojeda 8:12 PM Ding's update (posted on the RfL Zulip chat (separate from the Rust-lang's Zulip)): > First of all, it has been some hectic two weeks which I was predominantly occupied by oncall duties. Nevertheless, I have stroked some small wins so far. > ## `(p)init` > Other than the [library PR to enable concurrent experimentation](https://github.com/rust-lang/rust/pull/142518), I have been working on the compiler internal to type check. The intricacy here is that we might have to slightly deviate from how closure were type checked- the HIR type checking only looks into the projection predicates but for `init`s we should look into both the trait predicate `<{init block} as Init<T>>` and `<{init block} as Init<T>>::Error = E` to establish expectation on the target type `T` and the error type `E`. I am getting on top of that. What comes next should be performing the actual type checking on the `init` expression. > ## `arbitrary_self_type` > I wish that I could have done more. At the moment I am still trying small things in the name resolution and I need more time. I don't have something concretely working at the moment. > ## The ASM challenge > I am grooming the [`libclang` PR](https://github.com/llvm/llvm-project/pull/143424) to merge. There has been unexplained CI failures that I am investigating. Miguel Ojeda 8:14 PM https://rust-for-linux.zulipchat.com https://hackmd.io/@rust-lang-team/r1hbM_gVgx https://hackmd.io/@rust-lang-team/r1hbM_gVgx#support-for-pointers-with-asm_const-Support-for-pointers-with-asm_const-rust128464 Boqun Feng 8:19 PM I probably know why Ding posted there. Background: we have a bi-weekly meeting for RFL developers (hence there is a zulip channel for that, which is not public yet). During the RustWeek, I met with Ding, and he showed his interest on more Rust-for-Linux work, Therefore I offered to add him to our bi-weekly meeting, and the corresponding zulip. I also *jokingly* said as a result he needed to submit weekly reports. It was a JOKE, I swear. But I think Ding just make a good use of that joke ;-) Ramon de C Valle 8:20 PM I didn't know about the minutes doc and how to add something to it. If we have time, I'd like to add: https://github.com/rust-lang/rust/pull/123617 https://github.com/rust-lang/rust/pull/142681 Wesley Wiser 8:25 PM +1 to what Josh is saying. Maybe "on by default if retpoline is enabled" is the right move. The flag can still exist and allow you to opt-out At the same time, consistency with clang/gcc is also good :) Ramon de C Valle 8:27 PM Consistency with Clang also has a security property for mixed language bianries that you could assert that you have all compilation units with a certain mitigation applied For some mitigations if you omit a flag for a compilation unit it just silently wouldn't apply it to these compilation units and you end up with a partially protected binary, and for some mitigations it makes them completely innefective Wesley Wiser 8:32 PM It's pretty common for debuginfo to have the full compilation flags per obj/module. I'm not sure if rustc is doing that currently. Miguel Ojeda 8:35 PM https://bugs.llvm.org/show_bug.cgi?id=52323 https://gcc.gnu.org/cgit/gcc/commit/?id=2196a681d7810ad8b227bf983f38ba716620545e https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 Wesley Wiser 8:36 PM Yeah rustc does not currently do this but certainly could: https://github.com/rust-lang/rust/issues/133224 Wesley Wiser 8:45 PM If turning off sanitizers can cause UB, does this need to be `#[unsafe(sanitizers(off))]`? Ramon de C Valle 8:47 PM Humm, I don't think there are any cases where turning them off would cause UB--I think we discussed it a bit in one of our meetings and couldn't come up with a case Tyler Mandry 8:51 PM https://doc.rust-lang.org/beta/rustc/codegen-options/index.html Wesley Wiser 8:56 PM Need to drop, see you next time! Tyler Mandry 8:56 PM Interesting precedent for attributes: https://doc.rust-lang.org/reference/attributes/debugger.html#the-collapse_debuginfo-attribute