Lang/RfL meeting 2024-11-06

People: TC, nikomatsakis, Miguel Ojeda, Alice Ryhl, David Wood, Wesley Wiser, Boqun Feng, Gary Guo, Josh Triplett, Xiang Fei Ding

Tracking issue

Next round of project goals

What would it take to reach "true" stability?

  • Compiler flags and so forth
  • rustdoc things
  • and other things

Plan: Miguel will come back with a list of 10 candidates. We will assess feasibility.

https://github.com/Rust-for-Linux/linux/issues/355

  • rustdoc + lang-features
    • lang because dealing with changes is hard and decentralized
    • rustdoc because the usage is a total hack (grep)
  • build std – super high value
    • Arm has some folks working towards it and is interested in it as a goal.
      • davidtwco: we're primarily interested in this so that some of our pointer authentication flags can be stabilized and used
  • flags needed for some production use case, e.g., some subset perhaps of

Start with a concrete use case

Language features were prioritized because it's harder to track and cope with variations across compiler versions.

Compiler flags are easier to deal with.

Miguel: regarding "critical" features, I think there are 3 "kinds" that we should look into:

  • Features that would require changing a lot of things on the kernel side, e.g. language features used in many places in the source code (unlike e.g. compiler flags) and that cannot easily be "abstracted away" so that we only need to change a single place (e.g. have a macro that expands into something that may change later, so that we only have to change a single place).

  • Features needed for a production use case, e.g. the ones used by the kernel config of popular distributions, Android…

  • Internal features (i.e. not even unstable) or implementation details that we rely on in the kernel side anyway in a hacky way, e.g. the rustdoc KUnit ones. They would require a new design as unstable first.

Debian / Rust 2024 and RfL

Will RfL adopt Rust 2024?

If it gets into Debian… wait a few releases… pick that next one as the next minimum… and use that?

Miguel: not 100% guaranteed (we have to see if others in the kernel have any problem upgrading the minimum there, i.e. generally we try to not upgrade the minimum unless there is a good reason, e.g. removing workarounds etc., but generally I think it is a good idea and I think we should try to do it to take advantage of the new Edition and migrate early before we get a lot more code into the kernel, and having it in Debian Stable is a good starting point)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084048

General tracking

Project goal updates got mentioned:

https://lwn.net/Articles/996585/

Select a repo