-
Notifications
You must be signed in to change notification settings - Fork 315
Implement initial background indexing of a project #1216
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
@swift-ci Please test |
Implements an initial background index when the project is opened. The following will be implemented in follow-up PRs: - Resolving package dependencies - Preparing dependent modules - Watching for file updates
… different unit files
Windows has `ProcessResult.ExitStatus.abnormal` instead of ` `ProcessResult.ExitStatus.signalled`
82964cf
to
0ae3d80
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
is it support other BSP or only Swift Package Manager? |
To start off, I’m only aiming to support SwiftPM. I just opened #1226 from my local to-do list so we can share ideas there. If you could comment there which BSP server you are using with SourceKit-LSP, that would be valuable. |
Merging this to unblock further work on background indexing. Will address review comments in follow-up PRs. |
let filesWithOutOfDateIndex = uris.filter { uri in | ||
switch indexStatus[uri] { | ||
case .inProgress, nil: return true | ||
case .upToDate: return false | ||
} | ||
} |
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.
Isn't this filtering already done by index(files:priority:)
?
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.
Good catch 👍🏽
result.append(argument) | ||
} | ||
result.append(argument) |
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.
Not sure if this matters in practice, but this would append -Xfrontend
twice if it's the last argument
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.
Oh, yes. Looks like we should just remove the inner result.append(argument)
// Fake an output path so that we get a different unit file for every Swift file we background index | ||
"-o", fileToIndex.pseudoPath + ".o", |
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.
I don't think it really matters, but I think you could use -index-unit-output-path
here
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.
Also just noticed this doesn't seem to respect IndexOptions's indexStorePath
, is that intentional?
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.
I don't think it really matters, but I think you could use
-index-unit-output-path
here.
Good idea. That does seem cleaner.
Also just noticed this doesn't seem to respect IndexOptions's indexStorePath, is that intentional?
Yes, that’s intentional. IndexOption.indexStorePath
is an artifact from index-while-building. Background indexing stores all its artifacts independently of the build folder, which ensures that it doesn’t conflict with real builds for now. It should thus also use a different index store path. Unifying background indexing and index-while building is part of #1270
// We consider a file's index up-to-date if we have any up-to-date unit. Changing build settings does not | ||
// invalidate the up-to-date status of the index. |
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.
I guess you have to touch
the file or something if you want to index it with up-to-date build settings?
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.
Still an open question: #1251
// TODO (indexing): Group index operations by target when we support background preparation. | ||
for files in outOfDateFiles.partition(intoNumberOfBatches: ProcessInfo.processInfo.processorCount * 5) { |
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.
Worth a comment explaining the batching size? Or does it not matter since this will change once we support preparation?
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.
// We need to import all of TSCBasic because otherwise we can't refer to Process.ExitStatus (rdar://127577691) | ||
import struct TSCBasic.ProcessResult |
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.
Comment says we're importing all, but actually only importing ProcessResult 🤔?
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.
Oh, yeah. I was just stupid when I wrote the comment.
return | ||
} | ||
guard !buildSettings.isFallback else { | ||
// Only index with real build settings. Indexing with fallback arguments could result in worse results than not |
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.
When could this actually happen? We're not using index-while-building here, so it seems like an odd case. Presumably having something is better than nothing, but even if you added a "do we have anything in the index" check, that would still be odd as then we'd index it the first time and not again after that.
/// Adjust compiler arguments that were created for building to compiler arguments that should be used for indexing. | ||
/// | ||
/// This removes compiler arguments that produce output files and adds arguments to index the file. | ||
private func adjustSwiftCompilerArgumentsForIndexStoreUpdate( |
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.
This all makes me sad, we really need a "please don't output anything mode". Though... how that would then work with "oh but actually do output the index" is certainly a reasonable question 😅
Address review comment to #1216
Implements an initial background index when the project is opened.
The following will be implemented in follow-up PRs: