stricter hidden type wf-check [based on #115008]

[lcnr]

Original work by @aliemjay in #115008. A huge thanks to them for originally figuring out this approach ❤️

Fixes #114728
Fixes #114572

Instead of adding the WellFormed obligations when relating opaque types, we now always emit such an obligation when defining the hidden type.

This causes nested opaque types which aren't wf to error, see the comment below for the described impact. I believe this change to be desirable as it significantly reduces complexity by removing special-cases.

It also caused an issue with RPITIT: in defaulted trait methods, we add a Projection(synthetic_assoc, rpit_of_trait_method) clause to the param_env. This clause is not added to the ParamEnv of the nested coroutines. This caused a normalization failure in fn check_coroutine_obligations with the new solver. I fixed that by using the env of the typeck root instead.

r? @oli-obk

[lcnr]

I removed this, cc #106038 (comment) @aliemjay

I do not think this special-case is worth it and it's fairly fragile, as we cannot check that nested opaque types are well formed while in the defining scope. While I am still positive that the previous behavior was sound, having to allow types which aren't well-formed adds complexity which I don't think is worth it here.

[oli-obk]

broke my brain for 20 mins, but makes sense now

[aliemjay]

@bors try @rust-timer queue

[bors]

⌛ Trying commit af0d508 with merge 1659600...

[aliemjay]

Context: we're discussing whether the following code is valid despite the fact that the hidden type impl Sized is not technically well-formed because T: 'static is not known in test fn. However, if we consider the full context where the nested opaque type is defined impl Trait<&'static T, Assoc = impl Sized>, I believe we can safely assume that T: 'static holds.

trait Id<X> { type Ty; }
impl<X> Id<X> for () { type Ty = X; }
fn test<T>() -> impl Id<&'static T, Ty = impl Sized> {}

This was accepted as a valid defining use in #106038 and will be rejected with with this PR with the concern of increased complexity.

This causes nested opaque types which aren't wf to error, see the comment below for the described impact. I believe this change to be desirable as it significantly reduces complexity by removing special-cases.

This breaking change is not necessary for the soundness fix here and thus I prefer to at least have it in a separate PR.

Regarding the complexity concern, I believe we can keep supporting this behavior in a less complicated way than in #115008. The previous implementation in #115008 was unnecessarily complex because I wanted to have a perf baseline by emitting the least possible number of WF obligations. Moreover, I think that nested opaque types are special enough to have their own hir::OpaqueTyOrigin variant and this would arguably make the added complexity more acceptable.

[aliemjay]

This causes nested opaque types which aren't wf to error, see the comment below for the described impact. I believe this change to be desirable as it significantly reduces complexity by removing special-cases.

Oh, this would also disallow a more natural pattern that is much more likely to appear in the wild:

// This is rejected currently because of #96146 but even when this is fixed
// it would still be rejected by this PR with an error that requires `T: 'static` bound in `test`
fn id<T>(s: &T) -> &T { s }
fn test<T>() -> impl Fn(&T) -> impl Sized {
  id
}

[bors]

☀️ Try build successful - checks-actions
Build commit: 1659600 (1659600f7b9206c1651294a59c681822cd8ba6c7)

[lcnr]

I have strong feelings here and believe we should not support this behavior.

---

Regarding the complexity. My main concern is not the behavior of check_opaque_meets_bounds. I strongly believe that the following statement should be true:

We should always be able to assume, and verify, that all types are well-formed in the current context.

Allowing these patterns breaks this assumption at the point where we define the nested opaque type. This is fragile in two ways:

We will have to be careful when emitting WF constraints to avoid this breakage going forward. As shown by this PR. It is very subtle why my approach broke the wf-nested.rs tests while your approach in #115008 did not. Your approach only emits WellFormed obligations when relating opaques. We therefore avoid checking well-formedness of nested opaques as we eagerly replaced the nested opaque with an inference variable in project_and_unify_type:

rust/compiler/rustc_trait_selection/src/traits/project.rs

Lines 259 to 269 in 71a7b66

	// For an example where this is necessary see tests/ui/impl-trait/nested-return-type2.rs
	// This allows users to omit re-mentioning all bounds on an associated type and just use an
	// `impl Trait` for the assoc type to add more bounds.
	let InferOk { value: actual, obligations: new } =
	selcx.infcx.replace_opaque_types_with_inference_vars(
	actual,
	obligation.cause.body_id,
	obligation.cause.span,
	obligation.param_env,
	);
	obligations.extend(new);

This is not done in the new solver. We'd have to work around it there to continue to support this, for example by also eagerly replacing opaques with inference variables.

Even more importantly, we have to worry about accidentally leaking the non-wf type to somewhere which accepts well-formed types. We already have multiple unsoundnesses caused by a lack of WF checks, e.g. #98117. I do not want to make it more difficult to fix such issues as that may end up forcing nested opaques to be well-formed.

---

Supporting this pattern by amending the environment while defining nested opaque types seems a lot more acceptable. However, I believe that doing so is far from trivial.

---

Finally, I don't think this behavior is (very) desirable or consistent with the rest of Rust. I feel like "this was accepted as a valid defining use in #106038" is mostly irrelevant as the concern in #106038 (comment) ended up mostly slipping through and there hasn't been any official team approval of this behavior.This diverges from the behavior of where-clauses where such reasoning is not supported:

trait Id<X> { type Ty; }
impl<X> Id<X> for () { type Ty = X; }

fn test<T>() 
where
    (): Id<&'static T>,
    // (): Id<&'static T, Ty = &'static T>
    // both of these bounds error
{}

I do agree that supporting the following is generally desirable:

fn id<T>(s: &T) -> &T { s }
fn test<T>() -> impl Fn(&T) -> impl Sized {
  id
}

However, even this is imo not a strong argument to not land this PR as is. We currently do not support defining higher-ranked opaque types at all. Trying to do so always errors. I will push against any such attempts until the new solver is exclusively used as I am very much unsure how to soundly handle this when using semantic lookup for the opaque type storage.

Once implied bounds are explicitly handled and checked (necessary to fix #25860), we can support the above pattern without needing to support non-wf types as the type would now only be used inside of the Binder with the right bounds.

---

This breaking change is not necessary for the soundness fix here and thus I prefer to at least have it in a separate PR.

I don't. I consider the breakage for RPIT to have already been FCP'd as part of #115008.

However this is still a regression:

trait Id<X> { type Ty; }
impl<X> Id<X> for () { type Ty = X; }
fn test<T>() -> impl Id<&'static T, Ty = impl Sized> {}

We should probably ignore the wf-check nested RPIT, similar to nested TAIT.

We could separate the removal of the nested TAIT special-case into a separate PR, but given that the added WF-checks during borrowck reduce the breakage caused by that I don't think such a split is desirable. I personally don't have the energy and motivation to first land the approach of #115008 and then move the WF-checks, breaking wf-nested.rs in a separate PR.

[rust-timer]

Finished benchmarking commit (1659600): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.8%	[3.8%, 3.8%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.2%	[-3.2%, -3.2%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.0%	[4.0%, 4.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.0%	[4.0%, 4.0%]	1

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.7%, 0.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.7%, 0.7%]	1

Bootstrap: 650.304s -> 650.995s (0.11%)
Artifact size: 311.18 MiB -> 311.16 MiB (-0.01%)

[oli-obk]

The two regressions have similar up and down fluctuations over the last few weeks.

@rustbot label: +perf-regression-triaged

[oli-obk]

@bors r+

This may be stricter than necessary, but we can relax it later if we realize this is supportable in the new solver

[bors]

📌 Commit af0d508 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit af0d508 with merge 09bc67b...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 09bc67b to master...

[rust-timer]

Finished benchmarking commit (09bc67b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.5%, -2.2%]	5
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.7%	[1.7%, 1.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 647.585s -> 646.206s (-0.21%)
Artifact size: 175.07 MiB -> 175.06 MiB (-0.01%)

[lcnr]

This checks that RPIT are well-formed in more cases, fixing a soundness issue.