You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an issue in Xcode 12.5 where Swift applications will fail to debug as the search paths for some headers cannot be reconstructed. This is due to a recent change that de-duplicates header search paths when combining clang flags to create the Swift AST expression context. The issue we have is include paths like:
When resolving the relative destination path clang will search in subsequent include paths, but not prior ones. When we have multiple compilation commands with different headermap includes that rely on the same base path (this is a common case for Buck) the later base path includes will be skipped as they are already present in unique_flags. This will cause header lookups using those headermaps to fail.
I would be interested in thoughts on the best way to resolve this. We currently work around it by providing all the header map base paths through lldbinit config, but this is a bit messy. The other option I considered was moving duplicated search paths in the args to the end so as to preserve relative order between headermaps and search paths, which would work as long as conflicting headers cannot be found on earlier search paths (true in our case at least). Does this seem a reasonable approach?
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: 4c0116d6b109c0cdf06ea245d1439391
Issue Description:
We have an issue in Xcode 12.5 where Swift applications will fail to debug as the search paths for some headers cannot be reconstructed. This is due to a recent change that de-duplicates header search paths when combining clang flags to create the Swift AST expression context. The issue we have is include paths like:
-Isome/path/to/headermap.hmap
-Isearch/path/for/hmap
Where the headermap contains paths of the form:
somelib/someheader.h -> path/relative/to/later/search/path/someheader.h
When resolving the relative destination path clang will search in subsequent include paths, but not prior ones. When we have multiple compilation commands with different headermap includes that rely on the same base path (this is a common case for Buck) the later base path includes will be skipped as they are already present in unique_flags. This will cause header lookups using those headermaps to fail.
I would be interested in thoughts on the best way to resolve this. We currently work around it by providing all the header map base paths through lldbinit config, but this is a bit messy. The other option I considered was moving duplicated search paths in the args to the end so as to preserve relative order between headermaps and search paths, which would work as long as conflicting headers cannot be found on earlier search paths (true in our case at least). Does this seem a reasonable approach?
The text was updated successfully, but these errors were encountered: