Projections, lifetimes, and WF tracking issue (RFC 1214)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1214

• #26406
• #24622
• #23442
• #21748
• #25692
• #21953
• #27592
• Just take implied bounds from arguments. Implementing this probably requires improving check_method
• #27583
• Clarify WF checking for negative impls
• WF checking for object fragments where Self is not needed
• static methods should be able to assume that Self is WF, I believe (at least in trait impls)
• WF for trait objects should include the trait bounds
• #27675: object-safe traits can have associated types with unchecked bounds (unsoundness bug)

After warning cycle is complete

• Remove old WF check
• Remove RFC1214 origins and warnings
• Remove special treatment of ReEmpty in the outlives relation

Testing chart

Subject	Tests	Issues
OutlivesScalar	regions-outlives-scalar.rs
OutlivesNominalType	regions-outlives-nominal-type-struct.rs
	regions-outlives-nominal-type-enum.rs
OutlivesReference	all of the other tests
OutlivesObject	compile-fail/wf-in-obj-type-static.rs
OutlivesProjectionEnv	compile-fail/wf-in-obj-type-static.rs
WfObject, lifetime bounds	compile-fail/regions-wf-trait-object.rs
WfSlice	compile-file/wf-array-elem-sized.rs
const	wf-const-type.rs
struct, bound	wf-struct-bound.rs
struct, field	...many other tests...
enum, bound	wf-enum-bound.rs
enum, field	...many other tests...
trait, bound	wf-trait-bound.rs
trait, assoc type default	wf-trait-associated-type-trait.rs
	wf-trait-associated-type-region.rs
trait, assoc type bound	wf-trait-associated-type-bound.rs
trait, default fn, arg	wf-trait-default-fn-arg.rs
trait, default fn, return	wf-trait-default-fn-ret.rs
trait, default fn, where clause	wf-trait-default-fn-where-clause.rs
trait, fn, arg	wf-trait-fn-arg.rs
trait, fn, return	wf-trait-fn-ret.rs
trait, fn, where clause	wf-trait-fn-where-clause.rs
fn item, argument type	wf-in-fn-arg.rs
fn item, return type	wf-in-fn-ret.rs
fn item, where clause	wf-in-fn-where-clause.rs
inherent impl, where clause	wf-inherent-impl-where-clause.rs
inherent impl, fn, where clause	wf-inherent-impl-method-where-clause.rs
impl, assoc type default	wf-impl-associated-type-region.rs
	wf-impl-associated-type-trait.rs
fn type, argument type	wf-in-fn-type-arg.rs
fn type, return type	wf-in-fn-type-ret.rs
	wf-in-fn-type-static.rs
object type arg	compile-fail/wf-in-obj-type-static.rs
	compile-fail/wf-in-obj-type-region.rs
object safety	compile-fail/wf-object-safe.rs	#21953
fn(T): 'a affects T	compile-fail/wf-outlives-ty-in-fn-or-trait.rs
OutlivesProjection*	compile-fail/associated-types-outlives.rs	#24622
OutlivesProjection*	compile-fail/regions-assoc-type-outlives-container*.rs
OutlivesProjectionComponents	compile-fail/regions-close-associated-type-into-object.rs
implied bounds projection gap	compile-fail/regions-implied-bounds-projection-gap*rs

[jroesch]

cc me

[frewsxcv]

#27592 and #27583 can be checked-off in the original description

also, is there a way to determine which crates are impacted by the changes proposed by RFC 1214?

[mitchmindtree]

Just wanted to mention that I'm really excited for these changes to land on stable 😸 I have a lot of where clauses that look something like this:

where
    P::HLI: 'a + 'b,
    P::PatternGenerator: 'a + 'b,
    P::PhraseGenerator: 'a + 'b,
    P::Instrument: 'a + 'b,
    <P::Instrument as Instrument>::Source: 'a + 'b,
    P::Effect: 'a + 'b,
    P::Sample: 'a + 'b,
    P::BusId: 'a + 'b,

If I understand these WF changes correctly, they will save me hundreds of lines being able to simply write

where P: 'a + 'b`

instead.

[Stebalien]

Also fixes #21837.

[nikomatsakis]

@Stebalien

Also fixes #21837.

Not quite, because the interaction of implied bounds with variance is still not being properly handled.

[Stebalien]

@nikomatsakis sorry, it fixes the current test case so I assumed it fixed the bug.

[mitchmindtree]

I'd love to know the status of this 😸

BTW, It looks like we may be able to check off some of the related issues in the original comment: #24622, #23442, #21748, #25692, #21953 and as @frewsxcv mentioned, #27592 and #27583.

[brson]

@nikomatsakis Is this still P-high? Can it be lowered or assigned?

[pnkfelix]

assigning to self to double-check what's done and what's not

[pnkfelix]

I don't know with tracking issues in terms of the P-markings. I treat tracking bugs like this like metabugs, so I'm going to remove the P-high since I don't think we should assign priorities to metabugs.

[pnkfelix]

unassigning self; i haven't done anything with this and I don't think I'm the right person to take charge here.