[SourceKit] Compute type relations for global code completion items from the cache #40399
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci Please smoke test |
|
@swift-ci Please build toolchain macOS |
We don't need to convert them from/to integer
…t that can be cached and contextual part displayed to the user This allows makes the distinction between cachable and non-cachable properties cleaner and allows us to more easily compute contextual information (like type relations) for cached items later.
…textFreeCodeCompletionResult in a CodeCompletionResult
ahoppen
force-pushed
the
pr/typerelations-for-cached-global-results
branch
from
34b61ad to
021f316
Compare
…ypes Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes. This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed. Technically, we might miss some conversions like - retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported) - complex generic conversions (just too complicated to model using USRs) Because of this, we never report an `unkown` type relation for global items but always default to `unknown`. But I believe this PR covers the most common cases and is a good tradeoff between accuracy and performance. rdar://83846531
Allow a code completion item to have multiple result type to model the fact that we consider `Int` as both producing either a metatype and an instance type in code completion.
Previously, CodeCompletionResultTypes were stored on the heap and leaked. Instead, store them in a dedicated arena. While that arena is currently never released either, it cleans up the design and lays the foundations to release the arena on memory pressure.
ahoppen
force-pushed
the
pr/typerelations-for-cached-global-results
branch
from
021f316 to
e9ef698
Compare
|
This PR has gotten a little big. I’m splitting it up into multiple. The refactoring part is #40471. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends on #40163.
First, split code completion results into context free part that can be cached and contextual part displayed to the user.
This allows makes the distinction between cachable and non-cachable properties cleaner and allows us to more easily compute contextual information (like type relations) for cached items.
Then, compute type relations for cached items. Computing the type relation for every item in the code completion cache is way too expensive (~4x slowdown for global completion that imports
SwiftUI). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.This reduces the overhead of computing the type relations (again global completion that imports
SwiftUI) to ~6% – measured by instructions executed.Technically, we might miss some conversions like
Because of this, we never report an
unkowntype relation for global items but always default tounknown.But I believe this PR covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531