diff options
| author | Matthias Krüger <476013+matthiaskrgr@users.noreply.github.com> | 2025-06-27 22:13:03 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-06-27 22:13:03 +0200 |
| commit | 9108907a18d9b9ac46e361cced0fbfca6252f170 (patch) | |
| tree | 284d896275a3b2ceb1a211546997924c7147d337 /compiler/rustc_codegen_llvm/src/lib.rs | |
| parent | 190a1a7f747408d1936a81065665c687013f6141 (diff) | |
| parent | 87c8aa1ff6f320241e4161324946c1e23bc1617c (diff) | |
| download | rust-9108907a18d9b9ac46e361cced0fbfca6252f170.tar.gz rust-9108907a18d9b9ac46e361cced0fbfca6252f170.zip | |
Rollup merge of #142806 - compiler-errors:norm-ct-has-ty, r=lcnr,BoxyUwU
Normalize before computing ConstArgHasType goal in new solver This is a fix for rust-lang/rust#139905. See the description I left in the test. I chose to fix this by normalizing the type before matching on its `.kind()` in `compute_const_arg_has_type_goal` (since it feels somewhat consistent with how we normalize types before assembling their candidates, for example); however, there are several other solutions that come to mind for fixing this ICE: 1. (this solution) 2. Giving `ConstKind::Error` a proper type, like `ConstKind::Value`, so that consts don't go from failing to passing `ConstArgHasType` goals after normalization (i.e. `UNEVALUATED` would normalize into a `ConstKind::Error(_, bool)` type rather than losing its type altogether). 3. Just suppressing the errors and accepting the fact that goals can go from fail->pass after normalization. Thoughts? Happy to discuss this fix further. r? `@BoxyUwU`
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/lib.rs')
0 files changed, 0 insertions, 0 deletions
