diff options
| author | Michael Goulet <michael@errs.io> | 2023-07-06 20:11:39 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-07-06 20:11:39 -0700 |
| commit | de49a9f2f51757dced984a1b7f45e38d59985b5e (patch) | |
| tree | ef8308cbeb4b5a9a6fef87d0b317ed8789ef5a34 /compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp | |
| parent | 75febc6ed65c50f949264d7fa3be7be89fee0407 (diff) | |
| parent | 388c230cf77c633eeb9eee2e5388ce957c69797b (diff) | |
| download | rust-de49a9f2f51757dced984a1b7f45e38d59985b5e.tar.gz rust-de49a9f2f51757dced984a1b7f45e38d59985b5e.zip | |
Rollup merge of #112825 - compiler-errors:tait-defining-cycle, r=lcnr
Don't call `type_of` on TAIT in defining scope in new solver It's *never* productive to call `consider_auto_trait_candidate` on a TAIT in the defining scope, since it will always lead to a query cycle since we call `type_of` on the TAIT. So let's just don't. I've reserved this behavior just to `SolverMode::Normal` just to avoid any future problems, since this is *technically* incomplete since we're discarding a candidate that could *theoretically* apply. But given such candidate assembly *always* leads to a query cycle, I think it's relatively low risk, and I could be convinced otherwise and make this apply to both solver mode. I assume it's far less likely to be encountered in coherence, though. This is much more likely to encounter in the new solver, though it can also be encountered in the old solver too, so I'm happy to discuss whether this new behavior we even want in the first place... I encountered this in a couple of failing UI tests: * `tests/ui/type-alias-impl-trait/issue-62000-associate-impl-trait-lifetimes.rs` * `tests/ui/type-alias-impl-trait/issue-93411.rs` r? `@lcnr`
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
