Skip to content

Conversation

ChayimFriedman2
Copy link
Contributor

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.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 9, 2025
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.
Copy link
Member

@ShoyuVanilla ShoyuVanilla left a 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 😄

@ShoyuVanilla ShoyuVanilla added this pull request to the merge queue Sep 10, 2025
Merged via the queue into rust-lang:master with commit cd529a4 Sep 10, 2025
15 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 10, 2025
@ChayimFriedman2 ChayimFriedman2 deleted the update-rustc branch September 10, 2025 02:03
)

let sub_root = self.get_or_insert_sub_root(vid);
self.canonicalize_ty_var(CanonicalVarKind::Ty { ui, sub_root }, t)
Copy link
Contributor

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?

Copy link
Member

@ShoyuVanilla ShoyuVanilla Sep 10, 2025

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

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants