-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SourceKit] Make sure we reuse ASTContext in function bodies for solver-based cursor info #62574
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
daa2704
to
b204f2f
Compare
The SourceKit failure extension Invalid {
func tryIsSuccess(_ text: String?) {
// RUN: %sourcekitd-test -req=cursor -pos=%(line + 1):15 %s -- %s
guard let text else {}
}
} |
48821d8
to
65fc90f
Compare
@swift-ci Please SourceKit stress test |
1 similar comment
@swift-ci Please SourceKit stress test |
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.
The divergence between "cursor info" and other requests in IDEInspectionInstance
is getting bigger.
- Existence of code completion token
- Callbacks requirement
IgnoreSwiftSourceInfo
requirementSourceLoc
requirements
I feel passing different constant arguments depending on the request kind is not great for code readability.
We might want to reconsider whether we should continue to use a IDEInspectionInstance
for everything. Maybe it would be another IDEInspectionInstance
instance with different option, or different "cursor info instance" sharing some code (e.g. dependency checking) with IDEInspectionInstance
.
MapSourceLocIntoOriginalBuffer = [&SM, startOffset, tmpBufferID, | ||
newBufferID](SourceLoc Loc) -> SourceLoc { | ||
if (SM.findBufferContainingLoc(Loc) == newBufferID) { | ||
return SM.getLocForOffset(tmpBufferID, | ||
SM.getLocOffsetInBuffer(Loc, newBufferID) + | ||
startOffset); | ||
} else { | ||
return Loc; | ||
} | ||
}; | ||
|
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.
AFAICT, tmpBufferID
is a buffer ID in tmpSM
, not in SM
. So I believe SM.getLocForOffset(tmpBufferID, ...)
is not correct. This PR currently happens to work probably because the bufferID is the same 1
and the content is the same because there's no edits between the requests.
Also, I think this whole SourceLoc
conversion mechanism should be handled in SourceManager
.
I think we need to:
a) get offset, line, and column in the original buffer
b) compare source loc between beyond buffer IDs.
For (a) line and columns can be retrieved by getPresumedLineAndColumnForLoc()
. For offset
, I would add an optional parameter to SourceManager::openVirtualFile()
like offsetOffset
and remember it in VirtualFiles
, then create SourceManager::getPresumedLocOffsetInBuffer()
to retrieve the adjusted "offset".
For (b), SourceManager
knows the replaced source ranges, in ReplacedRanges
, so it should be able to "compare" the locations beyond source buffer if the loc is a part of ReplacedRanges
(like ASTScope
does).
Could you explore this option? I feel passing around this MapSourceLocIntoOriginalBuffer
is a too much burden for this purpose.
92b18ea
to
f48c64f
Compare
f48c64f
to
be0b18d
Compare
44bd218
to
9e745ed
Compare
This assures stable sort order when comparing solver-based and AST-based results.
…quest` The self nominal type decl needs to be passed as a parameter in here so this request doesn't tigger self nominal type computation, which results in an assertion failure.
…mmand Otherwise the order of sourcekitd-test’s output and the shell command is undefined.
If we cache the buffers between multiple requests we don’t pick up if the source file has changed on disk since we last read it.
…er-based cursor info The main problem that prevented us from reusing the ASTContext was that we weren’t remapping the `LocToResolve` in the temporary buffer that only contains the re-parsed function back to the original buffer. Thus `NodeFinder` couldn’t find the node that we want to get cursor info for. Getting AST reuse to work for top-level items is harder because it currently heavily relies on the `HasCodeCompletion` state being set on the parser result. I’ll try that in a follow-up PR. rdar://103251263
9e745ed
to
d18aca8
Compare
@swift-ci Please smoke test |
@swift-ci Please SourceKit stress test |
1 similar comment
@swift-ci Please SourceKit stress test |
Note to self: All cursor info verification failures in the stress tester are improvement. Most of them are because we now correctly return an optional and a non-optional result for an incomplete |
…igned to values in completion-like cursor info
d18aca8
to
9dfeb0a
Compare
@swift-ci Please smoke test |
The main problem that prevented us from reusing the ASTContext was that we weren’t remapping the
LocToResolve
in the temporary buffer that only contains the re-parsed function back to the original buffer. ThusNodeFinder
couldn’t find the node that we want to get cursor info for.Getting AST reuse to work for top-level items is harder because it currently heavily relies on the
HasCodeCompletion
state being set on the parser result. I’ll try that in a follow-up PR.rdar://103251263