diff options
| author | Stuart Cook <Zalathar@users.noreply.github.com> | 2025-05-06 16:28:43 +1000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-06 16:28:43 +1000 |
| commit | f14b4e69244c90096674b90b05d84b9914e8386a (patch) | |
| tree | d9233a2832b69f3a7719ddfabb661b1ad6e762d6 /tests/rustdoc/extern/auxiliary/rustdoc-extern-default-method.rs | |
| parent | d36e719fbca5c0a5654da12f84fead340074e661 (diff) | |
| parent | c0dfa44c485bb8a7a30f2b4b69827028b3d55c98 (diff) | |
| download | rust-f14b4e69244c90096674b90b05d84b9914e8386a.tar.gz rust-f14b4e69244c90096674b90b05d84b9914e8386a.zip | |
Rollup merge of #140678 - compiler-errors:dont-ice-on-infer-in-upvar, r=lcnr
Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis See the writeup in `tests/ui/closures/opaque-upvar.rs`. TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error. Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/197 r? lcnr
Diffstat (limited to 'tests/rustdoc/extern/auxiliary/rustdoc-extern-default-method.rs')
0 files changed, 0 insertions, 0 deletions