---
title: "Lang/RfL meeting 2025-04-09"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-04-09
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-04-09/with/511235256
url: https://hackmd.io/lRj_IUMWS8GxYmZjdS_vGQ
---

# Lang/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

[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)

### 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](https://hackmd.io/@flip1995/By87NXIc1g) 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`.