T-lang/RfL meeting addendum: Review of desired Rust language features for Rust-for-Linux

--- title: "T-lang/RfL meeting addendum: Review of desired Rust language features for Rust-for-Linux" tags: ["T-lang"] date: 2024-02-12 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-02-12 url: https://hackmd.io/r556bZKeSdu0cWwurlHjpw --- # Review of desired Rust language features for Rust-for-Linux This focuses on lang features, not features for libs or other areas. These are very preliminary assessments giving rough sizing (small/large/PhD-sized), and need to be cross-checked with others. ----- https://github.com/Rust-for-Linux/linux/issues/354 > Make `unsafe_op_in_unsafe_fn` the default dialect in a future edition. JT: Easy, and already in progress. > pinned-init: better ergonomics for Pin, perhaps as a language feature. JT: Hard, with some of the more exotic potential solutions rising into PhD territory. There are a few possible paths here, ranging from directly addressing Pin initialization to making Pin easier and more transparent to use in general to providing better ways of handling self-referential strutures in general. > Will `&mut T` be always treated as `*mut T` for `!Unpin` types? JT: Answering the question should be easy-to-medium; needs further review and discussion. Providing better solutions for Pin will range from hard to PhD, see above. > likely/unlikely JT: Easy. Being worked on somewhat. Current state is trending towards attributes on match/condition arms, like `#[cold]`. Need to check current status, and find out if current proposed solutions will work for Rust-for-Linux. > Some feature to help with partial borrowing, e.g. "view types". JT: Hard, but highly desirable. We've talked for years about having ways of doing partial borrows of data structures. Most of the difficulty here seems likely to be in design of how we present this feature to the user, rather than in the implementation. > "Custom prelude": A more general prelude_import feature that allows us to avoid writing boilerplate in every kernel module (i.e. in every crate), e.g. `#![no_std]`, `#![feature(...)]`, use kernel::prelude::*;, etc. JT: Easy; primary difficulty will be designing how we want to present this to the user. JT: We have `-Z crate-attr` already, which would work for things like `#![no_std]` and `#![feature(...)]`; that crosses compiler and lang. We should figure out what it would take to stabilize that. For custom prelude modules, we would need some design work, though I would expect that if `use kernel::prelude::*;` were the *only* line required that'd be less onerous. > `static_assert` JT: Easy. The facilities to implement this already exist, though we should have a native version. There's been some discussion recently about making top-level `const { }` blocks work, and about making `const { assert!(...) }` Just Work. > `build_assert` JT: Need clarification on how this is different from `static_assert`. > A way to elegantly handle "noop conditional compilation wrappers". JT: Easy. If I'm understanding correctly, this is asking for two things: - An `allow(unused_parameters)` that's narrower than `allow(unused_variables)` (easy). - An elegant way to conditionally mark a function as exising-but-no-op rather than not-existing. Also easy, and primarily a matter of interface design. I would expect, though, that this might be better done as a macro. - Relatedly, we should have ways of doing simple attribute macros declaratively without requiring proc macros. That's harder, but highly desirable. > quote as part of the freestanding standard library. > syn as part of the freestanding standard library. JT: Providing something like these as part of the Rust standard library is hard (dealing with interface design and stability). JT: There are other solutions for these, as well, such as making it possible to write more macros declaratively without requiring proc macros, such as attribute macros and derives. > A way to easily export in the prelude macros generated by macros. JT: Need to understand the issue better here. JT: In general, we need a better story for handling. macro visibility. Best guess: hard, because it touches name resolution. Highly desirable though. > A way to prove blocks of code / functions do not panic. JT: Hard to PhD-level. A narrowly scoped version may be more feasible. Needs a detailed look at the kinds of things needed and the kinds of code being called. > `feature(min_specialization)` JT: PhD-level. Nobody currently has a plan for a version of this that's sound. JT: We *might* be able to reduce this to "hard" with a plan for an expressly unsafe feature, as long as we could make it unsafe-to-implement-a-specialization rather than unsafe-to-use-a-specialization. Whether we *want* to do that is another question. errs: AFAIK min_spec is sound, but the `rustc_unsafe_specialization_marker` is not. > `feature(lint_reasons)` JT: Done, FCP in https://github.com/rust-lang/rust/issues/115980 completed, just need to ship the stable feature. > `UnsafeAliased` JT: Hard. Expect this to primarily be an issue of design and presentation to the user, rather than implementation. > `feature(const_refs_to_static)` JT: Seems easy? Likely blocked on bandwidth from wg-const-eval, but doesn't seem particularly difficult to support. errs: oli is working on this > Inline assembly: asm goto support (`feature(asm_goto)`). JT: Easy, needs some implementation bandwidth. In progress: https://github.com/rust-lang/rust/pull/119365 > Inline assembly: memory operands support. JT: Easy to hard. Handling the simple cases should be easy, handling complex addressing modes may be harder, doing the interface design will probably average to medium-hard. Amanieu: The main difficulty is exposing this to the user. Each arch has many possible addressing modes with different restrictions. Boqun: Would it be possible that Rust implements the easy cases and set up some workflow for architecture people to submit their extension for complicated cases? Amanieu: The easy case already exists, just pass the address in a `reg`. For every arch-specific memory constraint we need to: - Pick a clear name for the operand constraint. - Define and document the constraints on the address (absolute? pc-relative? register offset? what is the allowed range/alignment for the offset?). Boqun: I see, that makes sense. What I really want to see is that we can motivate one or two architectures to try to implement first. Do we know who works in Rust language on behalf of some architecture might be interested? I could try to copy paste what GCC has for ARM64, but I could only do the documentation part since I don't know much about compiler internals. ----- https://github.com/Rust-for-Linux/linux/issues/2 TODO