================
@@ -881,6 +886,35 @@ diagnoseFrameworkInclude(DiagnosticsEngine &Diags,
SourceLocation IncludeLoc,
<< IncludeFilename;
}
+/// Return true if a shadow has been detected and the caller should
+/// stop and return the first-found file and module, false otherwise.
+static bool checkAndStoreCandidate(
+ ModuleMap::KnownHeader *SuggestedModule, OptionalFileEntryRef
CandidateFile,
+ StringRef CandidateDir, DiagnosticsEngine &Diags, StringRef Filename,
+ SourceLocation IncludeLoc, ModuleMap::KnownHeader &FirstModule,
+ OptionalFileEntryRef &FirstHeader, SmallString<1024> &FirstDir) {
+ if (!FirstHeader) {
+ // Found the first candidate
+ FirstHeader = CandidateFile;
+ FirstDir = CandidateDir;
+ if (SuggestedModule)
+ FirstModule = *SuggestedModule;
+ return false;
+ }
+
+ if (FirstDir != CandidateDir) {
+ // Found a second candidate from a different directory
+ Diags.Report(IncludeLoc, diag::warn_header_shadowed)
+ << Filename << FirstDir << CandidateDir;
+ if (SuggestedModule)
+ *SuggestedModule = FirstModule;
+ return true;
+ }
+
+ // Found a candidate from the same directory as the first one
+ return false;
----------------
tahonermann wrote:
Clang elides duplicate search paths during search path ordering. I think
finding the same header file in the same location can only happen in some cases
where the same include path is present in both the quoted search path and angle
search path (and that might only be in existing cases where Clang doesn't match
GCC behavior). It could also happen with the corrected MSVC search path
ordering from [my draft PR](https://github.com/llvm/llvm-project/pull/105738),
but since MSVC doesn't support `#include_next`, it doesn't really matter.
https://github.com/llvm/llvm-project/pull/162491
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
