HackMD
Lang/RfL meeting 2025-03-12
Attendance
People: TC, Miguel, Niko, Alice Ryhl, davidtwco, Benno Lossin, Boqun Feng, Gary Guo, Wesley Wiser, Josh
Tracking
KCFI: -Csanitize-kcfi-arity support in rustc
Miguel: First case (in recent times) where we have somebody from the kernel coming, there is some flag in Clang, we need the equivalent in rustc, the flag is simple, the PR is simple, if we could get it merged, great. Then they can use the nightly toolchain and use that to easily test on their side.
davidtwco: I can assign myself and we can take a look.
-Zbinary-dep-depinfo
Miguel: We may be able to emulate this in the build system (at least for kernelspace crates).
Alice: How does make know which .rs files are part of a module? i.e., if I touch this rs file, this module needs to be rebuilt.
Miguel: Those are covered without the flag already.
davidtwco: https://github.com/rust-lang/rust/issues/63012 is our tracking issue for this.
Miguel: I'm planning to investigate this and confirm we can remove it. It doesn't seem like it's something that the compiler team is looking to remove immediately, so as long as it does not go away suddenly, it is fine.
davidtwco: It's something that we use as part of bootstrapping, so it's unlikely we'll remove it.
davidtwco: Actually, I'm not sure why it couldn't just be the default, but we'd need to look into it more closely.
Wesley: I looked at it a few weeks ago. I think it kind of makes sense to stabilize but we might have some other options than what's currently implemented depending on how our .d files are being used.
Arbitrary self types v2
Stabilization was blocked on:
That's now merged. Now it's block on:
And it's also now blocked on a concern about having a plan for how we'd later allow self: Pin<Ptr> self types.
We're probably going to need another item owner and implementor to drive this forward. Maybe Ding would be a candidate for this.
NM: Regarding #136776, I've come to the conclusion we shouldn't do a FCW but instead do the hard error but add targeted help suggestion. Maybe it could even be machine-applicable. We'd tell people to use transmute.
Derive smart pointer
This now has no outstanding concerns and will go into FCP with one more checkbox.
Unsizing coercion for tuples was removed in:
Given that, nikomatsakis closed the tracking issue.
Blog post about how the RfL project goal has gone
Niko has a draft started on this.
Canonical list of compiler flag requests
davidtwco: There are compiler flags listed on https://github.com/Rust-for-Linux/linux/issues/355 and https://github.com/Rust-for-Linux/linux/issues/2 - which is the proper list to be looking at? How are these prioritized between these? Which list should we be looking at here?
Miguel: #355 is not implemented flags, #2 is implemented flags needing stabilisation.
asm_goto
This is waiting on review of a Reference PR.
Support for pointers with asm_const
Feature request:
https://github.com/rust-lang/rust/issues/128464
Implementation unblocked by https://github.com/rust-lang/rust/pull/137180, and initial step is https://github.com/rust-lang/rust/pull/137686
Within RfL, having this has been identified as something that would be very helpful.
Implementation is now in progress:
https://github.com/rust-lang/rust/pull/137686
Probably we'll do an RFC here after the experiment.
Is naked_asm used by kernel?
Not really. Kernel can use .s files – but "global asm" is used.
2025 goals
https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html
ABI-modifying compiler flags
The RFC was accepted by T-compiler:
https://github.com/rust-lang/rfcs/pull/3716
There's a PR that started work on this:
https://github.com/rust-lang/rust/pull/133138
We've created tracking issue:
https://github.com/rust-lang/rust/issues/136966
Niko pinged azhogin on Zulip to see whether they are interested in continuing the work they started in https://github.com/rust-lang/rust/issues/133138.
There was back and forth on that. We're still not sure whether azhogin is willing to continue on it, so this one is blocked on looking for an implementor.
Alice: The current solution assumes that target modifiers with = can only take one value, but that doesn't work for e.g. sanitizers, where you can enable more than one.
davidtwco: I may be able to find some time to work on this.
Extract dependency information, configure no-std externally
Miguel is planning to look into this flag, and then discuss with everyone here.
One of the questions is whether we could skip core and do it only for the non-sysroot crates.
We last discussed it in:
https://hackmd.io/Jq3Xo0ZARAKNsRBC3lXkEA
tmandry had said:
tmandry: Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing. (we don't understand this point)
This is part of what Miguel is looking into.
Miguel: We can cross this out at the moment (see -Zbinary-dep-depinfo discussion above) If compiler wants to remove this flag, please let us know, but we're going to try to remove our use of this.
Rustdoc features to extract doc tests
We understand this to be implemented. Miguel talked with Guillaume at FOSDEM, and he's interested in implementing this in the kernel. He's looking into that.
The first iteration of this patch was sent to the kernel:
https://lore.kernel.org/rust-for-linux/20250228163844.945140-2-guillaume1.gomez@gmail.com/#r
Miguel: The way he did it requires to know the post-processing that rustdoc does, and thus requires hard-coding certain knowledge on the user side, e.g. we still need to find particular strings:
let doctest_code = doctest_code.replace(
"fn main() { fn _inner() -> Result<",
"fn main() { fn _inner() -> core::result::Result<",
);
We discussed this here:
https://github.com/rust-lang/rust/pull/134531#discussion_r1894610592
I'd like to see how we could make this more flexible for users (Linux kernel and others).
What's implemented is better than what we had before, but we can do better than this still, so we shouldn't stabilize what's now here, as it would lock us in.
Clippy configuration
There's a discussion involving flip1995:
Flip1995 wrote this pre-RFC: https://hackmd.io/@flip1995/By87NXIc1g
Miguel: Either a file or flags would be OK for the kernel. In some ways, having flags is easier for the kernel and other things with custom build systems.
What we need is that Clippy does not break in the future when using it. For that, there are a few aspects:
- The stability of each of the configuration keys and values (currently we use: msrv, check-private-items and disallowed-macros).
- The stability of the .clippy.toml file (i.e. its existence). The kernel does not necessarily need that it is a file – we could also use flags, for instance.
- The stability of the CLIPPY_CONF_DIR environment variable. The kernel uses it since it supports builds outside the source tree and thus we need to point it to the source tree so that it finds .clippy.toml. If we were not to use the .clippy.toml, file, this would not be needed.
- How to handle different compiler versions: for other tools (e.g. rustc), the kernel already handles passing different sets of flags depending on the compiler version. It would be easy for us to do the same for Clippy if the configuration options could be passed that way. Otherwise, if it is a file, there is the question of how to handle unknown keys/values. The kernel could also consider generating the configuration file on the fly, to avoid that issue.
This is waiting on movement on the clippy side.
Blessed way to rebuild std
https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html
David's team at ARM has talked through a document about how to go about this. The next step is putting out a kind of vision document about what we should be doing. The immediate goal will be the parts of it that are needed for RfL.
Wesley, Josh, and some others on the Cargo team have reviewed the document and are giving feedback. It's in the pre-pre-RFC stage.
There's still a lot of iterating on the right design. We somewhat have to flesh out the entire design to know what we can do for the first piece. The piece for RfL will then be the first one to stabilize, as it will be the easiest.
Josh has volunteered to be the champion for this on the Cargo side, and iterate on this to get the document to a state that addresses concerns raised by members of the Cargo team.
What kind of compiler flags will Rust-for-Linux need?
https://github.com/Rust-for-Linux/linux/issues/2
Wesley sent a PR to stabilize -Zdwarf-version.
https://github.com/rust-lang/rust/pull/136926
Wesley has proposed FCP merge here and is enthusiastic about doing it. If there's a bug here, it'd be in LLVM. This is leaned on heavily in other places.
It's currently waiting for checkboxes on the FCP.
cfg(no_global_oom_handling)
RfL doesn't use this any more, but it's still in the code for Linux 6.12 which is an LTS kernel.
We could backport the commit that removes the use. Otherwise, this caps the maximum Rust version (which would not be a great look).
In discussion, it sounds likely on the kernel side this could be removed from LTS.
From Zulip:
Daniel Paoliello:
We are still using this in the Windows kernel. Unfortunately, using kernel::alloc is not an option for us since it's GPLed.
Miguel: This is now gone from the new kernel and it's been backported to LTS.
So Linux does not use it anymore, and we have removed it from our RfL tracking.
Disabling the orphan rule
https://github.com/rust-lang/rust/issues/136979
From the 2025-02-26 meeting we talked about RfL using the nightly feature for #[fundamental] as the best workaround for testing here.
