HackMDLang/RfL meeting 2025-04-09
Attendance
People: TC, Josh Triplett, Alice Ryhl, David Wood, Wesley Wiser, Gary Guo, Miguel Ojeda, Boqun Feng, Benno Lossin, Xiang Fei Ding
Tracking
Stabilize derive(CoercePointee) (blocked on #136764 / #136776)
Probably nobody is motivated to get this in under we do arbitrary self types, and that one has some other work we want to do.
Stabilize arbitrary self types v2 (blocked on #136764 / #136776)
There's still the casting thing for the type_id hack. We've decided to just break that, but there's some diagnostic work still here to do. But the big issue here is what we've decided to do with respect to pin and other related cases.
support for pointers with asm_const Support for pointers with asm_const rust#128464
The asm_goto one is basically solved. The only thing left is using asm_goto with output operands. This isn't immediately needed for the kernel.
For this issue, for asm_const, there's a draft PR:
https://github.com/rust-lang/rust/pull/138618
This only implements the LLVM backend.
We still have this issue nominated and we can take it up on the lang side.
ABI-modifying compiler flags
There are some PRs waiting on review here.
https://github.com/rust-lang/rust/pull/138736
Configure no-std externally
There's an RFC up about --crate-attr.
https://github.com/rust-lang/rfcs/pull/3791
There's a compiler FCP ongoing on that. No concerns have been filed.
This is basically already implemented. The RFC is explaining how things already work, though there may be some small differences between the RFC and the implementation. So after the RFC is accepted, we'd expect a small reconcillation PR and then a stabilization PR.
Rustdoc features to extract doc tests
There are some things hardcoded in the current implementation. There's an ask to Guillaume here.
Clippy configuration
Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with flip1995.
-Zsanitize-kcfi-arity
This was merged in:
https://github.com/rust-lang/rust/pull/138368
On the RfL side, the plan is to test it, and then if it all looks good, we'll expect a stabilization PR.
Problem with no_sanitize and CFI violations with FineIBT enabled
There's a situation here where even when no_sanitize is used, it doesn't work correctly.
Regarding the formattting issue discussed related to this, this PR might be relevant:
https://github.com/rust-lang/rust/pull/115954
Bindgen issues
https://github.com/rust-lang/rfcs/pull/3718
https://github.com/rust-lang/rust/issues/59154
https://github.com/rust-lang/rust/issues/100743
https://github.com/rust-lang/rust-bindgen/issues/2179
https://github.com/rust-lang/rust-bindgen/issues/867
https://github.com/rust-lang/rust-bindgen/issues/2725
https://github.com/rust-lang/rust-bindgen/issues/1538
https://github.com/Rust-for-Linux/linux/issues/353
https://github.com/Rust-for-Linux/linux/issues/354
(Look for "packed type" in the latter links.)
So there's an issue here where certain patterns used by RfL don't produce valid Rust when processed with bindgen. The bindgen people have an ask about a lang feature in order to solve this.
From https://github.com/rust-lang/rust-bindgen/issues/2725:
struct s {
int a;
int b;
} __attribute__((packed, aligned(8)));
#[repr(C, packed(8))]
#[repr(align(8))]
#[derive(Debug, Copy, Clone)]
pub struct s {
pub a: ::std::os::raw::c_int,
pub b: ::std::os::raw::c_int,
}
error[E0587]: type has conflicting packed and align representation hints
--> <source>:4:1
|
4 | pub struct s {
| ^^^^^^^^^^^^
This is a reduced case from the bcachefs bkey case: https://elixir.bootlin.com/linux/v6.14-rc6/source/fs/bcachefs/bcachefs_format.h#L199-L258
} __packed
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
/*
* The big-endian version of bkey can't be compiled by rustc with the "aligned"
* attr since it doesn't allow types to have both "packed" and "aligned" attrs.
* So for Rust compatibility, don't include this. It can be included in the LE
* version because the "packed" attr is redundant in that case.
*
* History: (quoting Kent)
*
* Specifically, when i was designing bkey, I wanted the header to be no
* bigger than necessary so that bkey_packed could use the rest. That means that
* decently offten extent keys will fit into only 8 bytes, instead of spilling over
* to 16.
*
* But packed_bkey treats the part after the header - the packed section -
* as a single multi word, variable length integer. And bkey, the unpacked
* version, is just a special case version of a bkey_packed; all the packed
* bkey code will work on keys in any packed format, the in-memory
* representation of an unpacked key also is just one type of packed key...
*
* So that constrains the key part of a bkig endian bkey to start right
* after the header.
*
* If we ever do a bkey_v2 and need to expand the hedaer by another byte for
* some reason - that will clean up this wart.
*/
__aligned(8)
Gary: I think this is a more repr (which also happens outside bcachefs) example:
#[repr(C, align(4))]
struct Foo(i32);
#[repr(C, packed)]
struct Bar(Foo);
this is rejected by rustc.
For the C equivalent of this, GCC will say Bar has alignment of 1, and MSVC will have alignment of 4.
#[repr(C)]
struct Foo(i32);
#[repr(C, packed)]
struct Bar(Foo);
MSVC will have alignment of Bar be 1.
Alice: What if we were to accept?:
#[repr(C)]
struct Foo(i32);
#[repr(C, packed, aligned(1))]
struct Bar(Foo);
Gary: Clang would reject that though.
TC: I've nominated the RfL for lang discussion.
Gary: There is a workaround (for the GCC, not MSVC ABI) for this particular case. We can generate an array with the natural alignment that you want. So instead of writing align(4), you would just do _align: [u32; 0].
https://github.com/rust-lang/rust-bindgen/pull/2734
RFC:
https://github.com/rust-lang/rust-bindgen/pull/2769
https://github.com/rust-lang/rust-bindgen/pull/2770
Josh: What about asking the C compilers to support an __assert_packed (old compilers: it wouldn't do anything, in new compilers it would assert it is actually packed; bindgen would not need packed anymore).
Check in pahole.
