[PATCH] D135220: [clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef

Duncan P. N. Exon Smith via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 6 08:47:45 PDT 2022


dexonsmith added a comment.

In D135220#3840257 <https://reviews.llvm.org/D135220#3840257>, @goncharov wrote:

> In D135220#3840177 <https://reviews.llvm.org/D135220#3840177>, @dexonsmith wrote:
>
>> In D135220#3839671 <https://reviews.llvm.org/D135220#3839671>, @goncharov wrote:
>>
>>> That change might be problematic for content addressing storages. E.g. clang/test/Driver/cl-pch-showincludes.cpp started to fail in my setup as clang/test/Driver/header{0,1,3,4}.h are all identical and can be symlinked. cc @dexonsmith
>>
>> FWIW, I agree with Ben that this change seems like it should improve consistency for symlinked content. Knowing the failure mode / having reproduction steps would be helpful to track down your corner case!
>>
>> (There are many subtle interactions around this stuff in clang so it’s hard to make forward progress.)
>
> What I see in this  clang/test/Driver/cl-pch-showincludes.cpp is that e.g. for run on :25 it now emits
>
> Note: including file: ...header2.h
> Note: including file:  ...header1.h
> Note: including file: ...header1.h
>
> instead of
>
> Note: including file: ...header2.h
> Note: including file:  ...header1.h
> Note: including file: ...header3.h
>
> as header3 -> header1. It's possbile to make it deterministic by making headers unique though.

And can you share environment details?

- What OS are you on?
- Which test files are linked to which?
- Are these symbolic links or hard links?
- (etc.)

Maybe you can even share steps to reproduce your environment?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135220/new/

https://reviews.llvm.org/D135220



More information about the cfe-commits mailing list