Lang/RfL meeting 2024-11-20

--- title: "Lang/RfL meeting 2024-11-20" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-11-20 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-11-20 url: https://hackmd.io/7WEVQjkBRuCPfJDkb4zvrQ --- # Lang/RfL meeting 2024-11-20 People: tmandry, Josh, TC, Miguel Ojeda, Alice Ryhl, Benno Lossin, Boqun Feng, David Wood, Gary Guo, Wesley Wiser [Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116) ## 2025H1 goals For more details on each, please also see https://github.com/Rust-for-Linux/linux/issues/2. ### Language: `feature(arbitrary_self_types)`. This one has been progressing, we'll create a new goal for 2025H1 to track the continued work. This seems reasonable both on the lang and compiler side. We should sync up with Adrian Taylor on this, especially regarding work in the new year. https://github.com/rust-lang/rust/issues/44874 ### Language: `feature(asm_const)` with support for raw pointers. There's a WIP implementation that works for inline but not global ASM. There's a big refactor needed to homogenize things. Gary thinks this could be achieved in 2025H1 for the inline asm part. The kernel currently only uses the inline asm part, though possibly we would need the global asm support in the future. Amanieu would really like for this to support global asm also eventually. https://github.com/rust-lang/rust/issues/128464 Both on lang and on compiler, we don't see any concerns here with a project goal. ### Language: `feature(asm_goto)`. https://github.com/rust-lang/rust/issues/119364 This one is blocked on a PR from Gary being reviewed. - https://github.com/rust-lang/rust/pull/131544 - https://github.com/rust-lang/rust/pull/131523 After these two go in, we might be able to file a stabilization PR. ### Language: `feature(derive_coerce_pointee)`. https://github.com/rust-lang/rust/issues/123430 This may be blocked on arbitrary self types. Other than that, we're likely good to stabilize this. @dingxiangfei2009: Starting to use this here: https://github.com/Rust-for-Linux/linux/pull/1130 Older version from Alice: https://lore.kernel.org/rust-for-linux/20240823-derive-smart-pointer-v1-1-53769cd37239@google.com/ ### rustc: Blessed way te rebuild `core` - `rustc`: A "blessed" way to rebuild `core`, i.e. the one from the sysroot: no source code changes, just different compiler flags. We essentially do something like the test `tests/run-make/core-no-fp-fmt-parse/rmake.rs`. Maybe something like `-Zbuild-std=core` is needed. Gary: We currently use cfg to remove compiler-builtins dependency. David: This is largely a `cargo` problem (which RfL doesn't use); there's not much that the compiler does for this. This is more of a policy question around `rustc_bootstrap`. Josh: There's the cargo work, there's where do I get the matching sources, there's what's the blessed path here (e.g. for feeding in dependencies), and there's the question (later down the road) of how to configure the feature flags in core. Josh: Of those things, settling the questions of how to provide the paths for dependencies and whatnot, seems the most important problem. Wesley: I've heard the cargo team would like if they could pass a compressed crate file to rustc. If we had that support in rustc, then we could maybe distribute `core.crate` as a rustup component. Then that's what you would pass to `rustc`. Wesley: We may need an unstable way to say that you can't specify feature flags for a crate, then have `core` use that, so that libs-api doesn't need to commit to those. Josh: We could just rename those to prefix them with `unstable_`. Then we could be clear that these aren't part of the stable API. Miguel: We currently pass `cfg(no_fp_fmt_parse)`. Wesley: The key thing to have here is a well defined stability policy. Josh: People want the ability to use different CPU feature flags. If we had a way to turn off floating point as a feature flag, that might work. ### rustc: `feature(compiler_builtins)` - `rustc`: `feature(compiler_builtins)` or, better, a way to disable/disallow certain intrinsics (e.g. for floating-point and 128-bit integers, since they get used by `core`). Miguel: Right now RfL uses a hack that is terrible. https://github.com/Rust-for-Linux/linux/blob/rust-next/rust/compiler_builtins.rs tmandry: Would this work as a target modifier? Probably we'd have to introduce `cfg`s that are enabled or disabled by it. Gary: One issue is that we do use e.g. adds on 128-bit types; it's only the multiplications and divisions that cause problems. Josh: Long term, it probably will be important to allow for building core with or without certain feature flags. Gary: I'd really like a stable `abort` intrinsic. Josh: That should be an easy ACP, modulo some name bikeshedding to indicate that this is an illegal instruction rather than a generic abort mechanism. ### Remaining project goal items to talk about in next meeting - `rustc`: A solution to replace the custom target specification file (including target features, modifiers, sanitizers...), i.e. enough command-line flags to replace it. - `rustc`: arch-related flags and target features/modifiers (so far): + arm64: `-Zbranch-protection`, `-Zfixed-x18`, `-Zuse-sync-unwind`. + x86: `-Zcf-protection`, `-Zfunction-return`, `-Zno-jump-tables`, `-Zpatchable-function-entry`, retpoline (`+retpoline-external-thunk,+retpoline-indirect-branches,+retpoline-indirect-calls`), SLS (`+harden-sls-ijmp,+harden-sls-ret`). + x86 32-bit: `-Zregparm=3`, `-Zreg-struct-return`. + LoongArch: `-Zdirect-access-external-data`. - `rustc`: production sanitizer flags: `-Zsanitizer=shadow-call-stack`, `-Zsanitizer=kcfi`, `-Zsanitizer-cfi-normalize-integer`. - `rustc`: build system: `-Zbinary_dep_depinfo=y`, `-Zcrate-attr` (for `no_std` and allowed features, related: custom prelude). - `rustdoc`: JSON output for doctests, i.e. the hack, i.e. `--no-run` and `--test-builder`. Alona and Guillaume (t-rustdoc) agree on the feature; Guillaume also agreed to it would be nice to have it as a goal. - Clippy: configuration file (`.clippy.toml` in particular) and `CLIPPY_CONF_DIR`. They are currently marked as unstable, as if the entire file may be deprecated. #### Discuss / wish-list / nice to have - Language: `feature(associated_type_defaults)`. - Language: `likely`/`unlikely`-like mechanism (there was a recent PR to fix the current intrinsics). - Language: Support packed types to be aligned or to contain aligned members (RFC ongoing), plus `bindgen` support. - `core`: C string equivalents (nul-terminated) for `core::panic::Location` (we could workaround on the C side). - `rustc`: `-Zunsigned-char` (not implemented yet). - `rustc`: ABI stability related flags for Android. - `rustc`: `-Zoverflow-checks=report` (not implementated; Mara wanted to drive features that would unblock this one). - `rustdoc`: External references map file (if someone, e.g. @lolbinarycat, is available). ## Any intrinsics needed/used? Does RfL currently use anything in `core::intrinsics`? ## Priority items for Rust 1.85 Any item that's in Rust 1.85, even as unstable, is something that RfL can use if Rust 1.85 ends up in Debian stable. ### Support overriding flags on the command line This came up for the Android build and was a problem. In general, the kernel allows users to pass "additional" flags as environment variables, rather than having to pass (again) the entire flag list (or having in the kernel side a way to manually filter previous flags). e.g. `--edition`, `--sysroot`, `--target` ### Orphan rules relaxation The ask would be a way to disable the orphan rule between the crates in the kernel. https://github.com/Rust-for-Linux/linux/issues/354 - see "Relaxing the orphan rule" item. > In the kernel, internal APIs are not stable (https://docs.kernel.org/process/stable-api-nonsense.html): any changes are required to fix users/callers as needed. Out-of-tree modules are expected to follow and change as needed too. Therefore, it makes sense to relax the orphan rule within the kernel. > > [ I asked @bjorn3 about this idea in 2022, and he suggested introducing "coherence domains", which we then discussed later on with @nbdd0121 et al.: "One option would be to introduce a concept of coherence domains whereby all crates in a coherence domain are considered as a monolithic whole with respect to the coherence rules. The standard library could then have a coherence domain and the kernel code could have another coherence domain.". It could possibly be useful for other multi-crate/workspace projects as well. ] > > Potential "2024 Rust project goal": https://rust-lang.github.io/rust-project-goals/2024h2/Relaxing-the-Orphan-Rule.html (PR:https://github.com/rust-lang/rust-project-goals/pull/3). > > Add two draft project goals: seamless C support, and relaxing the orphan rule rust-lang/rust-project-goals#3). > > Internals: https://internals.rust-lang.org/t/limited-opt-out-of-orphan-rule/21709. TC: As a process matter, the thing to do is to file an issue for a lang experiment here and lang nominate it.