-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[IDE] Perform extension binding after AST mutation #83613
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
This ought to be requestified, but for now let's split it into its own function.
This allows us to lazily bind extensions after mutating the AST, ensuring we don't prematurely kick the building of lookup tables.
Now that we correctly bind extensions after mutating the AST, this is no longer necessary.
3746520
to
deecd46
Compare
@swift-ci please test |
@swift-ci please SourceKit stress test |
@@ -5389,6 +5389,25 @@ class DefaultIsolationInSourceFileRequest | |||
bool isCached() const { return true; } | |||
}; | |||
|
|||
/// A request that allows IDE inspection to lazily kick extension binding after | |||
/// it has finished mutating the AST. This will eventually be subsumed when we | |||
/// properly requestify extension binding. |
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.
If I understand correctly, this is safe because we currently only perform cached operations in function bodies, right? It's kinda scary to use request evaluator to make sure this being executed only in the initial operation, and to hope cached operations don't add extensions.
But as an intermediate solution, I think this is fine.
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.
A cached operation should never add new extensions to the same SourceFile (and therefore ModuleDecl), instead when we do top-level cached completions we create a new main module within the existing ASTContext. This is fine though since this request is keyed on the ModuleDecl.
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 I know. I just thought this looked scary. 😅
IDEInspectionSecondPassRequest
unfortunately currently relies on mutating the AST after-the-fact, make sure we delay extension binding until after that has happened to ensure we don't attempt to prematurely build incomplete lookup tables. This also allows us to get rid of the ad-hoc extension binding logic intypeCheckContextAt
.