--- title: "Lang/RfL meeting 2024-06-05" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-06-05 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-06-05 url: https://hackmd.io/sxO9L8KxQny3AI95QlsGgg --- # Document to read: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html # Action items * Hassle lang team about derive-smart-pointer RFC * nikomatsakis to ask about ptr-in-const * tmandry to start a discussion in Zulip to flesh out requirements from RFL team around compiler flags and compare/contrast with items arising in Fuchsia/Android/MacOS/etc * nikomatsakis to reach out to Amanieu / embedded team # Discussion People: TC, Alice Ryhl, Andreas Hindborg, Benno Lossin, Boqun Feng, Danilo Krummrich, Gary Guo, Josh Triplett, Miguel Ojeda, nikomatsakis, tmandry, Vincenzo Palazzo, Xiang Fei Ding ## RFL on Rust CI tmandry: When I talked to the infra team about putting Fuchsia in Rust CI, the impression I got was that the policy questions should mainly go to the compiler team. There are infra questions about the implementation details. But I also want to be careful about setting expectations about timelines here. ### fixed-x18 * Alice proposed and implemented `-Zfixed-x18` which tells compiler not to use the register * compiler team maybe wants a target-feature: * "allowed to use x18 for ram" -- if this feature is set, then `fixed-x18` would be disable * need a write-up that summarizes what is needed from RFL side (e.g., new chipsets may add new features, etc) and also what Tyler Mandry is encountering * PR that lifts sanitizer restrictions * https://github.com/rust-lang/rust/pull/124676 ### custom builds of core/alloc * using rustc for core/alloc. -Zbuild-std is used for something else, and anyway it is getting removed. * need a way to build core/alloc in a stable way * just call on the root modules right now, works fine * have tests in rustc test-suite testing the patterns we use * need conditions under which it is stable to compile core/alloc * could be -Zbuild-std but that is presumably overkill * need an owner / liaison... * Amanieu ? * might be an area where a 1 year guarantee would be useful * things being removed * floating point * unicode * fallible allocation * no-rc * no-sync -- no atomics * 128 bits * different use cases * easy sell: * removing functionality that is not viable on the target architecture * harder sell: * want to leave our Rust atomics because we have our own * reason to exclude them: avoid accidental usage * already do some surgery on the object files generated by libcore * already do some things to redirect intrinsics from what LLVM does etc * expanding this surgery could exclude symbols we don't want, feels hacky * unifying intrinsics * in an ideal world we'd not "exclude" intrinsics but unify them, but the semantics have to be identical * tmandry: semantics are different I think, might be another use case for target customization * certain targets have software intrinsics, no atomics (at least for certain numbers of bits), etc NM: I wonder whether some in the embedded community might want to drive some of this work. ### other goals * orphan rules -- would be good for kernel * josh: would kernel be happy with "declare a set of friendly crates that can ignore the orphan rule amongst themselves" * miguel: we need two "coherence domains", we don't want to cause issues with stdlib * but for everything else in the kernel (including out of tree modules) we don't care * https://github.com/Rust-for-Linux/linux/issues/354 * "Seamless C Support" and "Contracts and Invariants" could be interesting for the kernel too * to be discussed offline / in the next meeting. ## Next meeting Let's meet next in two weeks on 2024-06-19. We'll use this same format for future meetings of going through the items in the project goals list and checking in on each of them to see what we can help to move forward.