Skip to content
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

feat: Refactor path lowering and serve a new path diagnostic #19127

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

ChayimFriedman2
Copy link
Contributor

For non-Fn parenthesized generic args (each time, I plan working on the diagnostic from #17590, then I discover that ty lowering needs another refactor so I proceed with a refactor and a trivial diagnostic to test it. But this time I believe is the last :) ).

Path lowering started to look like a mess, with each function carrying additional parameters for the diagnostic callback (since paths can occur both in type and in expression/pattern position, and their diagnostic handling is different) and the segment index, for the diagnostics report. So I refactored it from stateless functions on TyLoweringContext into stateful struct, PathLoweringContext, that tracks the process of lowering a path from resolution til assoc types selection.

(I really hope I'm not making @jackh726's work on the new trait solver a nightmare. Sorry!)

Lifetimes are elided in function signatures, and inferred in bodies.
And add a new diagnostic for non-`Fn` parenthesized generic args.

Path lowering started to look like a mess, with each function carrying additional parameters for the diagnostic callback (since paths can occur both in type and in expression/pattern position, and their diagnostic handling is different) and the segment index, for the diagnostics report. So I refactored it from stateless functions on `TyLoweringContext` into stateful struct, `PathLoweringContext`, that tracks the process of lowering a path from resolution til assoc types selection.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants