Skip to content

[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

Merged
merged 3 commits into from
Aug 13, 2025

Conversation

hamishknight
Copy link
Contributor

@hamishknight hamishknight commented Aug 8, 2025

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 in typeCheckContextAt.

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.
@hamishknight
Copy link
Contributor Author

@swift-ci please test

@hamishknight
Copy link
Contributor Author

@swift-ci please SourceKit stress test

@hamishknight hamishknight changed the title [IDE] Perform import resolution and extension binding after AST mutation [IDE] Perform extension binding after AST mutation Aug 10, 2025
@@ -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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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. 😅

@hamishknight hamishknight merged commit 5e27e83 into swiftlang:main Aug 13, 2025
6 checks passed
@hamishknight hamishknight deleted the next-step branch August 13, 2025 21:37
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.

2 participants