-
Notifications
You must be signed in to change notification settings - Fork 1.8k
internal: Upgrade rustc crates #20645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
8c2e57a
to
d03fd87
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last similar update improved our memory usages a bit. Hope this one would do so 😄
) | ||
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 yeah, we should end up with only one canonicalizer at some point :> but not totally sure how to get there even in rustc rn
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::Alias
may 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.