forked from OSchip/llvm-project
b3a0fa4863
(1) Collect headers under inner frameworks (frameworks inside other other frameworks). (2) Make sure we also collect the right header files inside them. More info on (2): Consider a dummy framework module B, with header Frameworks/B/B.h. Now consider that another framework A, with header Frameworks/A/A.h, has a layout with a inner framework Frameworks/A/Frameworks/B/B.h, where the "B/B.h" part is a symlink for Frameworks/B/B.h. Also assume that Frameworks/A/A.h includes <B/B.h>. When parsing header Frameworks/A/A.h, framework module lookup is performed in search for B, and it happens that "Frameworks/A/Frameworks/B/B.h" path is registered in the module instead of real "Frameworks/B/B.h". This occurs because "Frameworks/A/Frameworks/B/B.h" is scanned first by the FileManager, when looking for inner framework modules under Frameworks/A/Frameworks. This makes Frameworks/A/Frameworks/B/B.h the default cached named inside the FileManager for the B.h file UID. This leads to modules being built without consistent paths to underlying header files. This is usually not a problem in regular compilation flow, but it's an issue when running the crash reproducer. The issue is that clangs collect "Frameworks/A/Frameworks/B/B.h" but not "Frameworks/B/B.h" into the VFS, leading to err_mmap_umbrella_clash. So make sure we also collect the original header. Differential Revision: http://reviews.llvm.org/D20194 rdar://problem/25880368 llvm-svn: 269502 |
||
|---|---|---|
| .. | ||
| Frameworks | ||
| usr/include | ||