+Implement Open API Namespace Support (rust-lang/rust-project-goals#256)
+
+
+
+
+| Progress | ++ | +
| Point of contact | +|
| Champions | +cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols) + |
+
| Task owners | ++ | +
+
+
+| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +compiler (Oliver Scherer), lang (TC) + |
+
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
1 detailed update available.
+ +#![feature(pin_ergonomics)] (https://github.com/rust-lang/rust/issues/130494) to ensure compatibility between the two features (allow custom pin projections to be the same as the ones for &pin mut T)&T/&mut T such as field projections, auto reborrowing and more#![feature(field_projections)]We want users to be able to have two different types of projections analogous to &T and &mut T. Each field can be projected independently and a single field can only be projected multiple times in a shared way. The current design uses two different traits to model this. The two traits are almost identical, except for their safety documentation.
We were thinking if it is possible to unify them into a single trait and have coercions similar to autoreborrowing that would allow the borrow checker to change the behavior depending on which type is projected.
+There are lots of different possibilities for which syntax we can choose, here are a couple options: [Devon Peticolas][]->f/[Andrea D'Angelo][] x->f, [Devon Peticolas][].f/[Andrea D'Angelo][] x.f, x.[Fatih Kadir Akın][]/x.mut[Fatih Kadir Akın][], x.ref.[Fatih Kadir Akın][]/x.[Fatih Kadir Akın][]. Also many alternatives for the sigils used: x[Fatih Kadir Akın][], x~f, x.@.f.
We have yet to decide on a direction we want to go in. If we are able to merge the two project traits, we can also settle on a single syntax which would be great.
+There are two categories of projections: Containers and Pointers:
+MaybeUninit<T>, Cell<T>, UnsafeCell<T>, ManuallyDrop<T>. They are repr(transparent) and apply themselves to each field, so MaybeUninit<MyStruct> has a field of type MaybeUninit<MyField> (if MyStruct has a field of type MyField).&T, &mut T, cell::Ref[Mut]<'_, T>, *const T/*mut T, NonNull<T>. They support projecting Pointer<'_, Struct> to Pointer<'_, Field>.In the current design, these two classes of projections are unified by just implementing Pointer<'_, Container<Struct>> -> Pointer<'_, Container<Field>> manually for the common use-cases (for example &mut MaybeUninit<Struct> -> &mut MaybeUninit<Field>). However this means that things like &Cell<MaybeUninit<Struct>> doesn't have native projections unless we explicitly implement them.
We could try to go for a design that has two different ways to implement projections -- one for containers and one for pointers. But this has the following issues:
+We might be able to come up with a sensible definition of "container type" which then resolves these issues, but further investigation is required.
+&Custom<U>We want to be able to have both a blanket impl<T, F: Field<Base = T>> Project<F> for &T as well as allow people to have custom projections on &Custom<U>. The motivating example for custom projections is the Rust-for-Linux Mutex that wants these projections for safe RCU abstractions.
During the design meeting, it was suggested we could add a generic to Project that only the compiler is allowed to insert, this would allow disambiguation between the two impls. We have now found an alternative approach that requires less specific compiler magic:
ProjectableBase that's implemented for all types by default.impl !ProjectableBase for MyStruct; (needs negative impls for marker traits).where T: ProjectableBase to the impl Project for &T.impl<U, F> Project<F> for &Custom<U> where ... (needs negative impl overlap reasoning)We probably want negative impls for marker traits as well as improved overlap reasoning for different reasons too, so it is probably fine to depend on them here.
+enum supportenum and union shouldn't be available for projections by default, take for example &Cell<Enum>, if we project to a variant, someone else could overwrite the value with a different variant, invalidating our &Cell<Field>. This also needs a new trait, probably AlwaysActiveField (needs more name bikeshedding, but too early for that) that marks fields in structs and tuples.
To properly project an enum, we need:
CanProjectEnum (TBB) trait that provides a way to read the discriminant that's currently inhabiting the value.
+&Cell)match operator that will project all mentioned fields (for &Enum this already is the behavior for match)While implementing https://github.com/rust-lang/rust/pull/146307 we identified the following problems/design decisions:
+DropField trait is not user-implementableUnalignedField trait,I decided to simplify the first implementation of FRTs and restrict them to sized structs and tuples. It also doesn't support packed structs. Future PRs will add support for enums, unions and packed structs as well as dynamically sized types.
+ +| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras) + |
+
| Task owners | ++ | +
1 detailed update available.
+ +Recently we've been working on feedback on the multi-staged format of the RFC. We've also shared the RFC outside of our sync call group to people from a variety of project teams and potential users too.
+We're now receiving feedback that is much more detail-oriented, as opposed to being about the direction and scope of the RFC, which is a good indication that the overall strategy for shipping this RFC seems promising. We're continuing to address feedback to ensure the RFC is clear, consistent and technically feasible. David's feeling is that we've probably got another couple rounds of feedback from currently involved people and then we'll invite more people from various groups before publishing parts of the RFC formally.
+ +| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | +bjorn3, Folkert de Vries, [Trifecta Tech Foundation] + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Task owners | ++ | +
Help test the deadlock code in the issue list and try to reproduce the issue
+ +1 detailed update available.
+ +| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett) + |
+
| Task owners | ++ | +
1 detailed update available.
+ +Key developments:
+| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | +Taylor Cramer, Taylor Cramer & others + |
+
1 detailed update available.
+ +Current status: there is an RFC for auto impl supertraits that has received some discussion and updates (thank you, Ding Xiang Fei!).
The major open questions currently are:
+The current RFC proposes:
+trait Subtrait: Supertrait {
+ auto impl Supertrait {
+ // Supertrait items defined in terms of Subtrait items, if any
+ }
+}
+Additionally, there is an open question around the syntax of auto impl for unsafe supertraits. The current proposal is to require unsafe auto impl Supertrait.
auto implsThe current RFC proposes that
+impl Supertrait for MyType {}
+
+impl Subtrait for MyType {
+ // Required in order to manually write `Supertrait` for MyType.
+ extern impl Supertrait;
+}
+This makes it explicit via opt-out whether an auto impl is being applied. However, this is in conflict with the goal of allowing auto impls to be added to existing trait hierarchies. The RFC proposes to resolve this via a temporary attribute which triggers a warning. See my comment here.
Note that properly resolving whether or not to apply an auto impl requires coherence-like analysis.
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | +Benno Lossin, Alice Ryhl, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay) + |
+
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
1 detailed update available.
+ +Just removed the duplicate posts, guessing from a script that had a bad day.
+ +| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur) + |
+
| Task owners | +Pete LeVasseur, Contributors from Ferrous Systems and others TBD, |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | +Amanieu d'Antras, Guillaume Gomez, Jack Huey, Josh Triplett, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
1 detailed update available.
+ +Key developments:
+New areas found for further exploration
+| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +compiler (Manuel Drehwald), lang (TC) + |
+
| Task owners | +Manuel Drehwald, LLVM offload/GPU contributors + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | +(depending on the flag) + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +lang (Josh Triplett), lang-docs (TC) + |
+
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | +|
| Champions | +cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols) + |
+
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | +|
| Task owners | +
|
+
1 detailed update available.
+ +Key developments:
+Major obstacles
+| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett) + |
+
| Task owners | +oli-obk + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Task owners | +[Bastian Kersting](https://github.com/1c3t3a), [Jakob Koschel](https://github.com/jakos-sec) + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Task owners | +vision team + |
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
1 detailed update available.
+ +It is possible to now run the system with two different machines on two different architectures however there is work to be done to make this more robust.
+We have worked on ironing out the last bits and pieces for dequeuing benchmarks as well as creating a new user interface to reflect multiple collectors doing work. Presently work is mostly on polishing the UI and handing edge cases through manual testing.
+Queue Work:
+Ui:
+| Progress | ++ | +
| Point of contact | +|
| Champions | ++ | +
| Task owners | +
|
+
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | +compiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras) + |
+
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +
| Progress | ++ | +
| Point of contact | ++ | +
| Champions | ++ | +
| Task owners | ++ | +