Skip to content

Update index as files are modified on disk #1302

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 1 commit into from
May 15, 2024

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented May 15, 2024

Fixes #1251
rdar://127476161

@ahoppen ahoppen requested review from bnbarham and hamishknight May 15, 2024 05:21
@ahoppen ahoppen requested a review from benlangmuir as a code owner May 15, 2024 05:21
@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test

@ahoppen ahoppen force-pushed the watch-file-changes-index branch from 37d23f5 to e215736 Compare May 15, 2024 14:08
@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test

@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test Windows

We mark the targets of the changed file as well as any dependent targets as out-of-date. The assumption is that most likely the user will go back to any of the affected files shortly afterwards and modify them again. When that happens, the affected file will get re-indexed and bring the index back up to date.

Alternatives would be:
- We could we check the file’s interface hash and re-index other files based on whether it has changed. But at that point we are somewhat implementing a build system. And even if a new public method was introduced it’s very likely that the user hasn’t actually used it anywhere yet, which means that re-indexing all dependent modules would still be doing unnecessary work.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder, with fine enough dependencies and swift-driver support, whether some kind of incremental-mode-based indexing could make sense. But that's way off in the future 😄

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we had it, I’m not sure if we really want to do a whole downstream re-index. Say you add a new public function in a fairly low-level module then we would need to re-index the entire project based on incremental information because it might affect overload resolution. And that’s still quite a bit of work, considering that most likely nothing really changed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends how fine grained the dependencies are, in theory if you're adding a function called foo, you shouldn't need to rebuild anything that didn't do a lookup for foo

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s a dream for a far and bright future ✨

@ahoppen ahoppen force-pushed the watch-file-changes-index branch from e215736 to 546bb32 Compare May 15, 2024 18:00
@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test

@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test Windows

1 similar comment
@ahoppen
Copy link
Member Author

ahoppen commented May 15, 2024

@swift-ci Please test Windows

@ahoppen ahoppen merged commit b30b972 into swiftlang:main May 15, 2024
@ahoppen ahoppen deleted the watch-file-changes-index branch May 15, 2024 22:46
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this pull request May 17, 2024
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this pull request May 17, 2024
ahoppen added a commit that referenced this pull request May 20, 2024
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.

Decide which files we should re-index when the package is changed
3 participants