owned this note   changed a year ago  
Published Linked with GitHub

2023-09-11 Planning meeting

Updates

AFIT/RPITIT stabilization

Plan is to open a stabilization report "any day now". Draft here.

TAITs

a-mir-formality

Most current work is on using rustc to generate formality code via SMIR.

Niko to resume hacking and working on docs soon. One key thing I'm thinking about is reflecting the AFIT/RPITIT work, as well as picking up the work I was doing on fuzzing (I may start that over after consulting with some folks who understand fuzzing a bit more). Another direction I'm interested in going is talking more about coinductive trait semantics.

Trait solver refactor

Some progress during the start of august, after which @lcnr was on vacation: overflow handling and some work on the provisional cache, see https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/weekly.20progress.20updates for updates.

nikomatsakis: I believe there is an intermediate goal of using trait solver for coherence? I'd like to better understand the milestones.

Trait object upcasting

WIP stabilization report: https://hackmd.io/QggP6SJVTa2jb7DjGq0vrQ?both

Negative impls

currently have an FCP in https://github.com/rust-lang/rust/pull/112875, @lcnr still wants to take some time to look at this in more detail.
We need to merge Michael's PR https://github.com/rust-lang/rust/pull/112875, properly define the meaning of always applicable and implement that.
We need to our (Niko, lcnr and Santiago) meetings about it.

Polonius

lqd has prepared a PR that reimplements the existing borrow-check in a polonius style. The diff is in some ways fairly minimal. Effectively we change:

  • from a map Region -> Points that identifies, for each region, the points at which it is live (because some variable is used whose type mentions this region or one that it outlives);
  • to a map Point -> Loans that identifies, for each point, the loans that are live (because they flow into a region that appears in the type of some live variable).

This code is currently feature gated and "opt in". It imposes some minimal performance overhead, with one case (serde) being up to 6% slower. However, right now this means that it takes 6% more time to do BOTH the old analysis (unchanged) AND the new one. It's not yet clear what time would be if we did JUST the new one.

The current plan is to land the PR and then explore optimizations but also to do work that enables a flow-sensitive version (which would then accept more cases and actually deliver user-visible benefit). We have opened a topic highlighting that we would like to onboard at least one new contributor, but they have to be well-versed and have time to spend, or else it's likely mot worth the effort yet.

chalk-ty

No new changes

Nominated issues

4 open: https://github.com/rust-lang/rust/labels/I-types-nominated

Tracking issue for dyn upcasting coercion

Stabilization report draft: https://hackmd.io/QggP6SJVTa2jb7DjGq0vrQ?both

lcnr:

also, cc @rust-lang/types this feature needs pretty much the most involved builtin impls we have. Unsize<dyn SuperTrait>: dyn Trait is non-trivial , see e.g. #114036. I still think this feature is very much desirable and this is a cost we are willing to pay.

To add to the above point, I would like us1 to increase our requirements for stabilizing new features

#114036 dealt with an issue which is both quite subtle - the original approach in that PR added new ways to exploit #57893 - and the general issue of "projection bounds on trait objects have to be handled in some way", was afaict never mentioned anywhere during the stabilization process.

I have some ideas here, like requiring the stabilization report to again fully describe everything that is stabilized, referencing the implementation. I think starting the FCP without any summary of what is stabilized, or stating "implements RFC X", is bound to cause bigger issues going forward. But these ideas are my own and might not necessarily work out too well in practice. The types team will have an in-person meetup this year where I will try to talk about this and I am also interested in the opinions of others here via zulip or in-person.

lint incorrect implied bounds in wfcheck

Bevy regresses on

trait Trait: 'static {}
impl Trait for &'static () {}

struct Foo<T: Trait>(T);
impl Foo<&()> {}

lcnr:

rn this lints triggers for bevy with afaict no sensible way to silence the lint. Given that we may be able to avoid it by a sensible and small extension to implied bounds, we may be able to avoid this.

Discussion here: https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/.23109763.3A.20lint.20incorrect.20implied.20bounds.20in.20wfcheck/near/384780130

lcnr's idea is to make this pass:

trait Trait: 'static {}
impl Trait for &'static () {}

struct Foo<T: Trait>(T);
impl Foo<&()> {}

Associated type constraints on super traits allowing for unsound transmutation to trait objects

Probably a duplicate of #57893

Allow dropping dyn trait object's principal

Allows us to cast from dyn Trait + Send to dyn Send.

pnkfelix:

Discussed in T-lang triage meeting; our conclusion was that if immediate stabilization is desired, then @rust-lang/types is the right team to own authoring a stabilization report (or, if the effort for a stabilization report is unwarranted, then the PR author can instead add a feature gate), so this can remain S-waiting-on-team, but the relevant team is now T-types.

Three options:

  1. Stabilize immediately
  2. Put under dyn upcasting feature
  3. Put under separate feature gate

@_Michael Goulet (compiler-errors)|426609 said:

I'll write up a stabilization report here. While I think we should do this for consistency's sake, I don't think it's worth gating behind a feature gate and having it sit in stabilization limbo forever.

Types FCPs

5 ongoing: https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-types+label%3Aproposed-final-comment-period

Tracking issue for dyn upcasting coercion

Not a t-types FCP

Rework negative coherence to properly consider impls that only partly overlap

Allows

impl<T, U> PartialEq<&U> for &T where T: PartialEq<U> {}
impl<F> PartialEq<F> for F where F: FnPtr {}

compiler-errors:

I think this should go through a T-types FCP since it (partially) commits us to using the new solver. This PR can always be reverted in its totality, and negative coherence is a nightly feature anyways, so any risk is exceedingly thin, and we're not locked into anything per se.

The main points of this FCP:

  • The new negative coherence algorithm (see PR description for the change of algorithm)
  • Using the new trait solver in negative coherence
  • Removing the FnPtr trait hack, by adding a builtin Rigid: !FnPtr impl for all rigid types that are not fn ptrs (in this case, ty::Ref).

relax leak-check

Discussed in deep dive: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2023-08-28.20higher.20ranked.20subtyping.20and.20leak.20check

Seems like it warrants more discussion

Check RPIT and AFIT hidden types are well-formed considering regions

wf-check hidden types at definition site

Stabilize impl_trait_projections

Deep dive planning

12 proposals: https://github.com/rust-lang/types-team/issues?q=is%3Aissue+is%3Aopen+label%3Adeep-dive-proposal

Select a repo