Michael has made many PRs towards this effort!:
rust-lang/rust#116828
rust-lang/rust#116912
rust-lang/rust#116946
rust-lang/rust#116951
rust-lang/rust#116993
rust-lang/rust#117008
rust-lang/rust#117578
rust-lang/rust#117580
rust-lang/rust#117582
rust-lang/rust#117851
AFIT and RPITIT are stabilized with Rust 1.75.
Work on subsequent useful features (e.g. RTN) has kind of stalled due to dependence on the new trait solver.
The plan is to first stabilize Mini-TAIT.
In the October 2023 T-types meetup, we had a great and very collaborative session on TAIT that resulted in a proposal for a minimal TAIT stabilization named Mini-TAIT. We presented this to T-lang on 2023-11-08. However, there were only 3 T-lang members present, and the meeting failed to gain consensus as discussion revisited the #107645 FCP about how we notate what items are allowed to define the hidden type of some opaque.
To disentangle things, as the key aspects of the Mini-TAIT proposal are orthogonal to this notation, we've made T-lang nominations for each aspect of Mini-TAIT:
There is a dual T-lang/T-types FCP also related to TAIT (but also to RPIT) ongoing here:
And we're proposing a new Mini-TAIT restriction here:
The hypothesis is that this restriction could make it more plausible to later lift the "may define implies must define" restriction.
Blocked on first stabilizing Mini-TAIT.
The RFC was accepted:
https://github.com/rust-lang/rfcs/pull/3498
The tracking issue is:
https://github.com/rust-lang/rust/issues/117587
There's a PR for the implementation here:
https://github.com/rust-lang/rust/pull/116952
Stabilizing this in Rust 2024 is contingent on TAIT or some other solution for expressing precise captures stabilizing.
No update
No update
update: there's no work going on here. discussed the long term goal in the types team meetup, but are currently not working on it.
update: mostly blocked on new-solver, though @aliemjay is doing some work using the existing setup
Trait object upcasting is stable on nightly and is scheduled to go out with Rust 1.76.
The T-lang FCP happened here:
https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127881
This is the stabilization PR:
https://github.com/rust-lang/rust/pull/118133
Not much has updated on negative impls themselves.
Core now uses the new trait solver for negative coherence. It's a very cool algorithm.
We have experimental support for negative trait bounds for testing purposes.
Note that t-lang formed consensus on a plan to stabilize a subset:
https://github.com/rust-lang/rust/issues/68318#issuecomment-1832355185
There is a draft RFC here:
https://hackmd.io/ZmpF0ITPRWKx6jYxgCWS7g
There is also discussion of wanting "questionable trait impls":
https://github.com/rust-lang/rust/issues/68318#issuecomment-1832389222
This is tracked separately in:
No update
Update: WIP PR by @fmease in https://github.com/rust-lang/rust/pull/117164
Update: see https://lcnr.de/update/2023-12-01, main blocker is non-fatal overflow handling in the new solver.
No update
Status on roadmap/WG/location-insensitive prototype:
- up-to-date roadmap published
- location-insensitive analysis landed in rustc, with empirical evaluation that this is equivalent to NLLs until a-mir-formality formalism is available:
- differential testing via tests, fuzzing, and crater: asserting no differences in scopes compared to NLLs'
- fuzzing: has uncovered 2 issues, now fixed
- crater runs:
- first run uncovered a difference on 10 crates, same root cause
- fix PR landed, clean results on second run
- various cleanups of borrowck, NLLs, and legacy polonius have landed
- onboarding Amanda, starting with higher-ranked task from the roadmap
- no new progress on borrowck/polonius in a-mir-formality just yet on our side, but there are plans in ralf's team
- moving on to location-sensitivity
Current status on location-sensitive prototype:
- the most up-to-date details about future prototyping are in this hackmd, and evolved out of the two previous descriptions
- we've started looking into realizing this design in-tree, but it's still early days
This was the subject of the 2023-11-29 T-lang design meeting:
https://hackmd.io/LCUSAX5LSfqc4m7N4CWNPw
The T-lang consensus was:
Consensus: We're OK with going forward in the 2024 edition with type aliases being weak and working analogously with structs. We accept the fact that people may have to add redundant where clauses, even though we may relax that later. This path is forward compatible with later relaxing these rules within an edition. We won't block stabilizing this in Rust 2024 on other improvments to implied bounds being made. At the same time, we're open to future or concurrent work along two axes: 1) better unifying type aliases with other alias types (e.g. associated types), and 2) improving implied bounds generally for all alias types.
Update: currently focussing on stabilizing -Ztrait-solver=next-coherence first.
Blocked on new solver with non-empty environments ~> post -Ztrait-solver=next-coherence.
No update
No update
No update
No update
No update
update: not actively worked on, requires the solver to be more settled, currently not a main focus.
No update
No update
No update
I think this has been sitting around long enough, clearly a fix for https://github.com/rust-lang/rust/issues/73987 will not magically materialize. And even with https://github.com/rust-lang/rust/issues/73987 unresolved, as long as we don't let users write arbitrary-self methods on raw pointers, we can still change the autoref behavior later to use raw pointers when that is enough. So while these methods might have a footgun, they are still better than the status quo.
So I propose we move towards stabilizing this, and https://github.com/rust-lang/rust/issues/71146.
@rust-lang/types are you aware of anything that would block stabilizing a function that uses a raw slice pointer self type? (AFAIK these would be the first stable functions that do that.)
I think this has been sitting around long enough, clearly a fix for https://github.com/rust-lang/rust/issues/73987 will not magically materialize. And even with https://github.com/rust-lang/rust/issues/73987 unresolved, as long as we don't let users write arbitrary-self methods on raw pointers, we can still change the autoref behavior later to use raw pointers when that is enough. So while these methods might have a footgun, they are still better than the status quo.
So I propose we move towards stabilizing the raw pointer part of this. (I am less sure about the
NonNullpart.)
@rust-lang/types are you aware of anything that would block stabilizing a function that uses a raw slice pointer self type? (AFAIK these would be the first stable functions that do that.)
IMPLIED_BOUNDS_ENTAILMENT into a hard error from a lintClosed as accepted
rustc_type_ir-ificationClosed as accepated.
trait_alias feature'erased during analysis
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe