New Build System: Issue Navigator doesn't jump to errors in headers when header maps are disabled

Originator:ryan.brown
Number:rdar://FB7673400 Date Originated:April 23 2020
Status:Open Resolved:
Product:Xcode Product Version:11.4.1
Classification: Reproducible:
 
We disable header maps (USE_HEADERMAP = NO) to enforce that C++ headers are included using their complete path (e.g., "mycompany/foo.hpp", not just "foo.hpp"). When using the New Build System, this breaks the Issue Navigator: it doesn't jump to an error in the editor when clicking on an issue in a header. The Issue Navigator works when using the Legacy Build System.

The example project is the macOS Command Line Tool template with "USE_HEADERMAP = NO" and "HEADER_SEARCH_PATHS = include" set at project scope.

Steps to reproduce:
1. Clone https://github.com/ryb-ableton/XcodeNewBuildSystemIssueNavigatorBug
2. Open "XcodeNewBuildSystemIssueNavigatorBug.xcodeproj"
3. Build
4. Open the Issue Navigator pane
5. Click on the error (on the "I'm an error - try to navigate to me" text)

Expected:
Xcode jumps to the error in the editor

Actual:
An alert sound is played and Xcode does not open "foo.h"

Comments

I think I've found a workaround also to the issue with include paths.

If I replace the simple "../relative" in my Header Search Paths with "$(PROJECT_DIR)/../relative", then all the paths listed for includes are given as absolute in the sense that they will start with the absolute path to the project directory, and then the relative path is appended to that.

It looks like the Issue Navigator knows what to do in that case, and it is able to jump to the issue location resolving whatever relative components ".." etc. that it finds along the path, as long as it starts with an absolute path

By yyfede at Sept. 9, 2020, 9:34 a.m. (reply...)

More on this: it appears that -fdiagnostics-absolute-paths helps in some cases but there are still issues for which the jump to the issue location does not work:

-fdiagnostics-absolute-paths doesn't seem to have an effect on the paths printed to show the chain of includes that led to the issue, therefore even with that flag enabled, in some circumstances I get messages like:

`In file included from /absolute/path/Source.cpp:15: In file included from ../relative/include.h:4: /absolute/path/to/warning/location/header.h:1057:90: warning: implicit conversion changes signedness: 'unsigned int' to 'int' [-Wsign-conversion] `

When such a message is printed, Xcode fails to jump to the issue, and as you can see the line in the middle still lists a relative path.

That is because I have the "../relative" path in my Header Search Path. If I change it to the corresponding absolute path, the error message will only contain absolute paths and the jump to issue will work again, but obviously I cannot have the Header Search Path as absolute in my project because it would immediately break if someone checks out the whole project in another position on disk

By yyfede at Sept. 9, 2020, 8:46 a.m. (reply...)

Update on this: adding

-fdiagnostics-absolute-paths

to the compilation flags makes Xcode emit absolute paths for files when listing the issues it finds

By yyfede at Sept. 9, 2020, 8:17 a.m. (reply...)

I've played around with this and it seems to me that the issue happens when the path of the file that appears in the error message is a relative path.

If it's an absolute (obviously to an existing file), then Issue Navigator is able to jump to the file and line of the error.

If I'm correct, I see two possible reasons for that: 1) A parsing problem prevents issue nagivator from understanding relative paths at all, or 2) The relative paths in error messages are given starting from the directory that contains the Xcode project, but Issue Navigator thinks they are relative to a different origin, and fails to resolve them to the correct file.

I've been able to determine this because I have a Post Build script that emits messages using the format undestood by Xcode to point to the line within the script where the error occurred. I have noticed that it stopped working when I switched to the "New Build System" and now that I switched to emitting the full absolute path of the script, it works again. Unfortunately I don't know if it's possible to make Xcode and its tools emit absolute paths for their errors, too :(

By yyfede at Sept. 8, 2020, 2:57 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!