---
title: "Lang/RfL meeting 2025-01-15"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-01-15
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202025-01-15
url: https://hackmd.io/dG4FuNE-QCOyfQHpAlhNew
---
# Lang/RfL meeting 2025-01-15
## Attendance
People: TC, nikomatsakis, Alice Ryhl, Andreas Hindborg, Boqun Feng, David Wood, Gary Guo, Guillaume Gomez, Miguel Ojeda, Wesley Wiser, Xiangfei Ding, Jubilee Young
## Tracking
[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)
## CoercePointee
Commit that is making use of 1.84 (when rename occurred)...
https://github.com/Rust-for-Linux/linux/commit/47cb6bf7860c
...woohoo!!
## Project goal
https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html
* "hangover" from the previous
* re-stabilize CoercePointee -- Alice is looking at this
* Good opportunity to try out the new template
* stabilize arbitrary self types v2 -- Adrian Taylor is limited in time
* https://github.com/rust-lang/rust/issues/44874
* Next steps
* Wait ~1 week more to "let it sit"
* Can we get evidence that it's meeting its design goals?
* [Commit from RFL](https://github.com/Rust-for-Linux/linux/commit/c95bbb59a9b2)
* Polish and sort out the doc PRs
* Arbitrary self types v2: dev guide updates. rustc-dev-guide#2168
* Arbitrary self types v2: update reference. reference#1699
* Prepare a stabilization report
* Good opportunity to try out the new template
* Notes:
* Lang-team: we'll have to review restriction on generics
* notes on adrian's updates
* asm-goto -- ready for stabilization, not been merged yet, some editorial discussion about the Rust reference
* https://github.com/rust-lang/rust/pull/133870
* https://github.com/rust-lang/reference/pull/1693
* implementing [RFC #3716] to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth
* RFC status? Missing one of...
* cjgillot
* compiler-errors
* estebank
* spastorino
* PR that needs to be reviewed and landed
* petrochenkov may look at it
* https://github.com/rust-lang/rust/pull/133138
* Now in FCP
* non-ABI modifying flags from [RFL#2](https://github.com/Rust-for-Linux/linux/issues/2)
* the ability to extract dependency info, currently using `-Zbinary-dep-depinfo=y`
* 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.
* Process to stabilize:
* somebody needs to "propose it"-- FCP on the stabilization PR
* concern seems to bottom out in build-std...
* e.g., with dwarf-version, stdlib will give you the wrong thing no matter what you ask for
* -Zcrate-attr, used to configure no-std without requiring it in the source file
* Any real concerns here?
* `-Zunpretty=expanded`
* Output (expanded form) is not stable
* Just used for ease-of-use, development
* In practice `cargo expand` uses `RUSTC_BOOTSTRAP=1` and everybody uses it
* https://github.com/dtolnay/cargo-expand/blob/master/src/main.rs#L109
* Add the same caveat that we use for emitting MIR
* (Maybe add a test that it works with rustfmt?)
* `-Zno-jump-tables` -- move this to an "ABI-modifying flag" as it is an interoperability, interlinking hazard
* typical caveat around core/std, we basically just pass this to LLVM
* is there a "correctness or safety" issue?
* Gary: used for CFI, but the kernel build process checks this
* Building without these additional flags will manifest as objtool printing a large number of errors about missing ENDBR and if CFI is enabled (not currently possible) will result in incorrectly structured function prefixes.
* https://lore.kernel.org/rust-for-linux/20231009224347.2076221-1-mmaurer@google.com/ (though that commit enabled both the branch protection and jump-tables at the same time -- not sure if the jump-tables was required or not)
* `-Zdwarf-version`
* this is specific to a given invocation, if you mix it (or use precompiled libstd), you will get a mix
* debuggers and distributors must handle mixed DWARF4/DWARF5 anyways:
* most "changes" in DWARF5 were introduced by deprecating a DWARF4 section and introducing a new, additive DWARF5 section (or sections), so it is still valid to e.g. have the old section as well as the new section
* debuggers encountering unrecognized DWARF attributes from future versions can be expected to be handled gracefully
* `-Zdebuginfo-compression`
* there was some concern about whether or not Zstd support existed but it [seems like yes](https://github.com/rust-lang/rust/pull/125642)
* debuginfo compression is mostly handled by a set of arguments passed to the linker (there's a little bit of assembler antics sometimes). If the linker is our LLD, then zlib and zstd compression is supported by being bundled with our LLVM (as LLD is also one of LLVM's many faces). zstd is available since Rust 1.82.0
* https://maskray.me/blog/2022-01-23-compressed-debug-sections
* stable rustdoc features allowing the RFL project to extract and customize rustdoc tests (`--extract-doctests`);
* @imperio authored https://github.com/rust-lang/rust/pull/134531, up for review
* PR needs to land, RFL to validate design
* stabilization
* clippy configuration (possibly `.clippy.toml` and `CLIPPY_CONF_DIR`);
* Something like [this](https://doc.rust-lang.org/clippy/configuration.html)?
* use 3 options currently (msrv, check-private-items=true, disallowed-macros)
* real question is how "forwards compatible" to be
* e.g., allow and warn about unrecognized options
* [a blessed way to rebuild std](./build-std.md): RFL needs a way to rebuild the standard library using stable calls to rustc. Currently building the standard library with rustc is not supported. This is a precursor to what is commonly called `-Zbuild-std`; it is also a blocker to making full use of API-modifying compiler flags and similar features, since they can't be used effectively unless the kernel is rebuilt.
* Arm team took project goal https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html
* Work proceeds, should have an update in a few weeks with solid progress
* :tada: