Fix background indexing behavior if a source file is included in two targets via a symlink #1858
Conversation
|
@swift-ci Please test |
…targets via a symlink Consider the following scenario: A project has target A containing A.swift an target B containing B.swift. B.swift is a symlink to A.swift. When A.swift is modified, both the dependencies of A and B need to be marked as having an out-of-date preparation status, not just A.
ahoppen
force-pushed
the
symlink-target
branch
from
60c5f8d to
5eb460f
Compare
|
Updated the PR to dod the inference of source files with equivalent realpaths to |
| } ?? [] | ||
| } | ||
|
|
||
| func filesDidChange(_ events: [FileEvent]) { |
There was a problem hiding this comment.
Did you check what event ends up being sent for changing a symlink? Is it a delete + add or just a change?
There was a problem hiding this comment.
I did not. But it shouldn’t matter because we clear the realpath cache on any file event.
There was a problem hiding this comment.
Sure, I was wondering if we could limit it to eg. just delete/add rather than on change
There was a problem hiding this comment.
Even if I checked how it behaves on macOS, I don’t want to make inferences about how it behaves on various Linux distributions, so I think erroring on the side of caution is better here. Plus, recomputing a single realpath when a file is changed shouldn’t be that bad.
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
Consider the following scenario: A project has target A containing A.swift an target B containing B.swift. B.swift is a symlink to A.swift. When A.swift is modified, both the dependencies of A and B need to be marked as having an out-of-date preparation status, not just A.