Lang/RfL meeting 2025-06-04

--- title: "Lang/RfL meeting 2025-06-04" tags: ["T-lang", "design-meeting", "minutes"] date: 2025-06-04 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-06-04 url: https://hackmd.io/Hg5x_pp6SbK-J4jm9hbmJQ --- # Lang/RfL meeting 2025-06-04 ## Attendance People: - TC - Jubilee Young - Niko - Miguel Ojeda - Boqun Feng - David Wood - Alice Ryhl - Benno Lossin - Philipp Krones - Wesley Wiser - Tomas Sedovic - Josh Triplett ## Tracking [Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116) ## Stabilize derive(CoercePointee) Alice: I promised to use the new template but [FCP has apparently started](https://github.com/rust-lang/rust/pull/133820#issuecomment-2936062051). ## Stabilize arbitrary self types v2 * Ding has been working on an RFC because there were new open questions. * Niko to follow up with Ding. ## support for pointers with asm_const - https://github.com/rust-lang/rust/issues/128464 - https://github.com/rust-lang/rust/pull/138618 TC: lang-team discussed and found there were complications, so we wanted an RFC. Alice: There are a few concerns: * do we call it `const` or not? * how do we manage need to translate const pointer to sym + offset. Jubilee: Don't we need to translate to static + offset in other cases already? Alice: No, the only way to refer to a static today is sym, which doesn't have an offset. nikomatsakis: I think being able to have an offset was one of the big motivators for this feature. Alice: That plus being able to have a trait and an associated const instead of needing a macro. TC: Is this implemented? Alice: I see a PR from Gary... not merged. Conclusion: Blocked on an RFC, do we have any plan to do it? Alice: I would take a while to do it. Miguel: Maybe Gary since he implemented it on https://github.com/rust-lang/rust/pull/138618. *Action Item:* to ping Gary Guo and see if he is able to do it. ## Placement new / in-place initialization / `impl Init` Josh and Benno and Alice had a long discussion at RustWeek about this, and there's now a [draft proposal](https://hackmd.io/@aliceryhl/BJutRcPblx). [Document link](https://hackmd.io/@aliceryhl/BJutRcPblx) Josh: There's also a proposal for how this would allow "universal dyn-compatible traits". *Action Item:* Alice to share it and people to read it. *Action Item:* TC to consider adding to the lang-team agenda. ## ABI-modifying compiler flags * Implemented in the compiler by azhogin. * in the place you add new compiler flags, you can declare a flag as a *target modifier*. * What doesn't work is to have "flag specific error messages" in case you get it wrong. * "get it wrong" = link things with inconsistent target modifiers. * And there are several PRs adding this flag to various compiler flags. Niko: What stops us from stabilizing it? Alice: More that you stabilize a *flag* using the infrastructure. Alice: So for example we are now able to stabilize `fixed-x18`, also sanitizers, and ret-trampoline (spectre mitigation), and this called sls (straight-line speculation). We have PRs for those two flags. Once we have them, we can get rid of target-json in the kernel for now. Those are the only remaining things that we use that require target-json. nikomatsakis: That's a good milestone, let's knock out target-json and then start tackling flags for stabilization. jubilee: Maybe we should stabilize sanitizers first after that? jubilee: Are there things that aren't target modifiers that should be? - -Csoft-float - davidtwco: this flag is deprecated ([compiler-team#779](https://github.com/rust-lang/compiler-team/issues/779)) - -Ctarget-feature=-neon - davidtwco: we prohibit writing this ([#133417](https://github.com/rust-lang/rust/pull/133417)) - -Clinker-plugin-lto - -Cllvm-args - Possibly -Ccode-model and -Crelocation-model boqun asked: - -Zmin-function-alignment - No, it's always overalignable so it should never be ABI-breaking. - -Zpatchable-function-entry - Alice says maybe for the pre-nops jubilee: It seems https://github.com/rust-lang/rust/pull/135927 (retpoline) is at the bottom of the stack and we are waiting on the author to be ready? * retpoline PR: what is the next step? *Action item:* azhogin, are you ready for #135927 to be reviewed, what state is it in? And them mark it `@rustbot ready` azhogin = Andrew Hogin He works with Vadim Petrochenkov. ## Clippy configuration Philipp: Plan to address that during our [feature freeze](https://github.com/rust-lang/blog.rust-lang.org/pull/1613) over the summer. Question: Do we want configuration flags? Those are easier to the RFL project. Miguel: can manage both, depends on what you do with the unknown lints and those kinds of cases. If we can have a single file that's fine, but if we have to generate customized files, that's annoying. Flags are easier to customize, can easily create a list dynamically. Miguel: Anything we can do on our side? Philipp: We don't really have anyone actively working on it. @Jarcho expressed interest. I'll try to help out but can't promise availability during the summer. Happy to mentor anyone who is interested in contributing to Clippy. Miguel: currently used config options: `msrv`, `disallowed_macros`, `check-private-items`. Soon also `doc-valid-idents`. *Action item:* Try to recruit a contributor to work on it. ## Configure no-std externally Concept: Ability to pass a crate attr on the command line RFC #3791 is under FCP, waiting for a few boxes Jubilee: Some folks had concerns about a few particular attributes, some of which really ought not to be attributes at all, but that probably shouldn't block the thing overall. We just should carve out exceptions if we feel we need to. davidtwco: Pinged pending fcp people in t-compiler/private. ## Rustdoc features to extract doc tests Miguel provided feedback on the original impl because it still required the use of some hardcoded assumtions, didn't quite provide enough metadata. There is a PR with a new design to extend the capabilities. Next steps: land the PR, evaluate, and if it is sufficient, stabilize. *Action item:* Miguel to investigate whether this new set of metadata contains everything that is needed. ## `-Zsanitize-kcfi-arity` A new flag that appeared recently, no particular action item, until we stabilize kcfi, no action item. ## NUL-terminated filenames with `#[track_caller]` The ACP was accepted after some conversation at RustWeek and also a 3rd user showed up in the comments. Score one for in-person communication! Alice: https://github.com/rust-lang/libs-team/issues/466 [PR #135054](https://github.com/rust-lang/rust/pull/135054) is already in the bors queue! :tada: ## FFI Integer types Josh: Interested, what is this about? Alice: https://github.com/rust-lang/rust/pull/138290#issuecomment-2939629632 Another RustWeek. C++ folks discussed integer types in multiple sessions. It's also something RfL cares about because we had to make our own FFI module since `core::ffi` has the wrong types. nikomatsakis: /me so glad to not have been in these meetings omg C integer types make me eyes bleed Alice: biggest problem is `char`. Kernel passes a flag to make `char` unsigned but Rust makes it an `i8` on some platforms. Another one that is less critical but inconvenient is `long`: in the Kernel, `long` is always `isize`/`usize`, but Core FFI translates it to `u32` or `u64` (depending on the size of `usize`). It does this because of some Windows target where they don't match (although they do on other targets). Josh: These are both valid but ought to be separated. The char-signedness one seems like it could be "plumbed through" now that we have ABI-modifying flags. Changing this would be you incompatible with the C target but if you are effectively using x86-64-unknown-none you are defining your own target and this helps you to define that. Somebody pointed out that std is precompiled -- build-std of course addresses that -- but a cfg might be able to handle this in some fashion, we already use cfg's on the basis of the target, this could potentially be one of those. (confused --nikomatsakis) Josh: The u32/usize/etc thing has been a source of conversation several times and stalled out. There is a tension between platforms where `usize` == `size_t` and platforms where `usize` = `ptrsize_t` and in almost every case those are the same thing with possible exception of some fascinating platforms like the ARM Morello that do pointer tagging. Here `usize` could be the "bits of the pointer you can see" but pointers can be e.g. twice as big due to "bits you can't see" (the tag). Because of those platforms that have not demonstrated the ability to get ecosystem adoption, we are stalled out from unifying with what the ecosystem expects (both `size_t` and the size of a pointer). It seems like dealing with pointers where this is not true is sufficiently obscure that we shouldn't make everybody deal with it, the same way we don't expect everyone to deal with 16-bit platforms. I think we should agree that they are both the size of pointers and other platforms are going to have a hard time getting support and have to write an RFC and then this problem goes away. Miguel: I'm not sure how much this matters to us. TC: There were a number of things on nightly that were "nice to have" and some that were truly relied on. How close are we to building linux on stable Rust, just in terms of the language? At what point do you go rewrite the "nice to have" things? Miguel: In this case it's not even *nice to have*, it's just not implemented yet. Miguel: There are two missing types: https://github.com/Rust-for-Linux/linux/issues/2 TC: Once we get rid of all the feature flags, even if it still needs nightly for compiler flags and whatnot, it'd be good for us to declare partial victory. Niko: What is it that we really need to get rid of unstable language features. Alice: We'll probably always need unstable flags. Wesley Wiser: Worth writing something on blog.rust-lang.org once we're stable. Miguel: On the C side if you really need a new compile function, you can backport it. In the kernel they do features conditionally. Josh: You can wait for a feature to be stabilized, then start using it in the kernel and then you can opt in with bootstrap conditionally to support the older compiler. But on the new compilers you wouldn't need any bootstrap. Alice: We have a list of features we use (it can be an empty list) and we disallow everything else. Josh: One of the reasons for conditional bootstrap is: saying we want this feature that is stabilized. And we can look at when to opt into an old nightly version (to e.g. know not to use a nightly with a particular bug in that feature). Josh: To people in linux it feels like they're not using a stable language. ## Field projection Also a long discussion at RustWeek with Benno and Alice and Josh. :) Benno: There also is a [document](https://hackmd.io/@y86-dev/HkMBy6Hzlx) I would really like some feedback on :)