generalize: handle occurs check failure in aliases

[lcnr]

mostly fixes #105787, except for the for<'a> fn(<<?x as OtherTrait>::Assoc as Trait<'a>>::Assoc) eq ?x case in rust-lang/trait-system-refactor-initiative#8.

r? @compiler-errors

[lcnr]

exists because of <() as Trait<<?0 as Trait<()>>::Assoc>>::Assoc == ?0 have to update comment. With Projection goals the behavior is still broken, but I want to change it to emit alias-relate in the new solver in a different PR, at which point this should work.

[lcnr]

handling this correctly is HARD. We'd have to push the infer var to the place which introduced the binder and then have a nested Equate goal or sth.

idk how to handle this during coherence, ideally just succeed with equating and emit an Ambiguity predicate?

[lcnr]

potentially reachable with user type annotations? Probably not as the actual type inferred by HIR typeck also needs to contain an inference variable? 🤔

[compiler-errors]

this is still in draft, so marking as author so i can clean up my queue :>

@rustbot author

[lcnr]

This PR mostly fixes generalization for aliases, fixing #105787. It is therefore a (theoretical) breaking change.

Equating ?x == Alias<?x> previously failed. This is incomplete (and therefore allows overlaps via the implicit negative overlap check in coherence). This PR instead delays equality in this case, emitting a Projection goal. This projection goal then stalls until the projection can be normalized to a rigid type, in which case the occurs check is correct, or the projection cannot be normalized and stays rigid (due to a ParamEnv candidate).

It is non-trivial whether we can get trait solver overflow (in the old solver) for rigid projections, e.g.

trait Unnormalizable<T> {
    type Assoc;
}

struct Inv<T>(*mut T);

fn unconstrained<T>() -> T {
    todo!()
}

fn create<T, U: Unnormalizable<T>>(
    x: &U,
) -> (Inv<T>, Inv<<U as Unnormalizable<T>>::Assoc>) {
    todo!()
}

fn foo<T: Unnormalizable<U> + Unnormalizable<V>, U, V>() {
    let q = unconstrained();
    let (mut x, y) = create::<_, _>(&q);
    x = y; // equate `?x` with `<T as Unnormalizable<?x>>::Assoc`
    drop::<T>(q);
}

However, projection goals only constrain the term to the projection itself if we were able to select a ParamEnv candidate. As we do not have non-lifetime binders, this only happens if the projection does not contain type inference variables.

I believe that you can get solver overflow with specialization and default associated items, but idc 😁

This only fixes problem case 2 of rust-lang/trait-system-refactor-initiative#8. However, this is by far the easiest way to get an incorrect occurs check failure (and the only one I bothered to write a coherence unsoundness test for). This only impacts the old solver for projections containing bound variables (as we otherwise eagerly normalize and replace the projection with an inference variable).

I consider this to 1) be a step in the right direction and 2) necessary for future work on the new trait solver.

[lcnr]

should have done perf + crater 😅

@bors try @rust-timer queue

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

r=me after rebase

[lcnr]

@bors r+ rollup=never

[bors]

📌 Commit cf8a2bd has been approved by lcnr

It is now in the queue for this repository.

[compiler-errors]

@bors r+

approver is wrong

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Change prefetch to avoid deadlock #118488

[bors]

📌 Commit cf8a2bd has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit cf8a2bd with merge 90f22e7...

[lnicola]

This is going to fail, CC #118597. Maybe you can take a look, @compiler-errors, since you seem to be around.

Actually, @pietroalbini might be a better person to tag, sorry for the mix-up.

[compiler-errors]

@bors retry

kicking the job to avoid failure

[rust-log-analyzer]

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

thread 'main' panicked at src/tools/cargotest/main.rs:148:13:
assertion failed: status.success()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:36:43
make: *** [Makefile:51: check-aux] Error 1
  network time: Mon, 04 Dec 2023 11:09:26 GMT
##[error]Process completed with exit code 2.
Post job cleanup.

[bors]

⌛ Testing commit cf8a2bd with merge 25dca40...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 25dca40 to master...

[rust-timer]

Finished benchmarking commit (25dca40): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

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)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	2.7%	[2.6%, 2.7%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	1.7%	[1.7%, 1.7%]	1

Cycles

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

Binary size

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

Bootstrap: 672.674s -> 673.516s (0.13%)
Artifact size: 314.14 MiB -> 314.15 MiB (0.00%)