Swift and Objective-C targets still include project-wide header maps when HEADERMAP_INCLUDES_PROJECT_HEADERS=NO

Originator:e
Number:rdar://FB8115994 Date Originated:Jul 23, 2020 at 9:53 AM
Status:Open Resolved:
Product:Swift Compiler Product Version:Xcode 11.5 (11E608c)
Classification:Incorrect/Unexpected Behavior Reproducible:Always
 
Please describe the issue:
My understanding of the HEADERMAP_INCLUDES_PROJECT_HEADERS build setting is that setting it to NO will prevent a `*-project-header.hmap` file from being generated and passed to clang. Xcode's build setting reference (https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6) describes it:

> HEADERMAP_INCLUDES_PROJECT_HEADERS
> Specifies whether the header map contains a name/path entry for every header in the project, regardless of the headers’ target membership.

I'm unable to reproduce this behavior. I can set HEADERMAP_INCLUDES_PROJECT_HEADERS=NO on a target, and can confirm from the build log that a project-wide header map is being passed to the compiler. Using hmaptool (https://github.com/apple/llvm-project/blob/apple/master/clang/utils/hmaptool/hmaptool), I can confirm that that header map lists headers from outside the target.

This unexpected behavior appears to impact both Swift and C-based targets.


Please list the steps you took to reproduce the issue:
Reproduced on macOS 10.15.3 (19D76) with Xcode 11.5 (11E608c).

1. Open the attached sample project and build the "wtf-hmap" target.

2. main.m in wtf-hmap imports `framework.h`, which comes from outside the target and should fail when HEADERMAP_INCLUDES_PROJECT_HEADERS=NO. I added a warning to framework.h to reveal that it's being imported.

3. Look at the "Compile main.m" step in the the build log for the "wtf-hmap" target. Observe that clang is being passed a `wtf-hmap-project-headers.hmap` header map. On my system, this is:

    -iquote /Users/emw/Library/Developer/Xcode/DerivedData/wtf-hmap-bggjknjdtzjtsqfhvdzqmxddxgog/Build/Intermediates.noindex/wtf-hmap.build/Debug/wtf-hmap.build/wtf-hmap-project-headers.hmap

4. Using hmaptool (https://github.com/apple/llvm-project/raw/apple/master/clang/utils/hmaptool/hmaptool), dump the contents of `wtf-hmap-project-headers.hmap`. Observe that it includes "framework.h", even though that header isn't from the target being built. On my system:

    $ ./hmaptool dump /Users/emw/Library/Developer/Xcode/DerivedData/wtf-hmap-bggjknjdtzjtsqfhvdzqmxddxgog/Build/Intermediates.noindex/wtf-hmap.build/Debug/wtf-hmap.build/wtf-hmap-project-headers.hmap
    Header Map: /Users/emw/Library/Developer/Xcode/DerivedData/wtf-hmap-bggjknjdtzjtsqfhvdzqmxddxgog/Build/Intermediates.noindex/wtf-hmap.build/Debug/wtf-hmap.build/wtf-hmap-project-headers.hmap
    framework.h -> framework/framework.h


What did you expect to happen?
I expected compilation to fail when `main.m` quote-imported `framework.h`, because framework.h isn't in the search paths for the "wtf-hmap" target and I had set HEADERMAP_INCLUDES_PROJECT_HEADERS=NO.

I expected the arguments passed to clang in the "Compile main.m" step to not include the `wtf-hmap-project-headers.hmap` header map.
What actually happened?
The "wtf-hmap" target was able to import headers from outside the target.


File uploads:
wtf-hmap.zip: https://drive.google.com/file/d/1DdgPi0_SlQb2niTiL2CBfft7jgyz3Jcj/view?usp=sharing

Comments


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!