internal: Upgrade rustc crates#20645
Conversation
rustbot
added
the
S-waiting-on-review
They have to do with diagnostics, we could probably not support them but we will also someday want good diagnostics. The code is mostly copied from rustc.
A lot of simplification and fun.
ChayimFriedman2
force-pushed
the
update-rustc
branch
from
8c2e57a to
d03fd87
Compare
ShoyuVanilla
left a comment
ShoyuVanilla
left a comment
There was a problem hiding this comment.
The last similar update improved our memory usages a bit. Hope this one would do so 😄
rustbot
removed
the
S-waiting-on-review
| ) | ||
|
|
||
| let sub_root = self.get_or_insert_sub_root(vid); | ||
| self.canonicalize_ty_var(CanonicalVarKind::Ty { ui, sub_root }, t) |
There was a problem hiding this comment.
existing: why does this canonicalizer exists. The next solver canonicalizer is in rustc_next_trait_solver. I guess you need this canonicalizer outside of the trait solver 🤔 where?
There was a problem hiding this comment.
Actually, it has been introduced by me on #20578 and originally written by @jackh726 on a branch in his fork. I cherry-picked their branch as a starting point. And I didn't know that next-solver has it's own canonicalizer 😅
And it seems that current implementation is similar to rustc_infer's canonicalizer, which is mostly called within rustc_trait_selection::traits, the old solver but there are few places outside it like rustc_hir_typeck::method::probe::probe_op. I'll check whether we can use next-solver's canonicalizer directly
There was a problem hiding this comment.
👍 yeah, we should end up with only one canonicalizer at some point :> but not totally sure how to get there even in rustc rn
|
changelog fixup #20329 |
5 participants
The first commit adapts to changes in canonicalization. I really wait for a r-l/r sync so that we won't need to constantly do it manually. (If you can help - see #t-compiler/help > Dependency of both Chalk and rustc_type_ir fails r-a sync).
The second commit is where the fun is. The upgrade brings even more custom types. Yay for type safety!
@rust-lang/rust-analyzer, @rust-lang/types the remaining source of dynamic ID types are aliases, which are a problem because
TyKind::Aliasmay carry either a type alias id or an opaque type id. If you can have an idea how to sort that - that'll make me really happy.