This is an archive of the discontinued LLVM Phabricator instance.

[clang] Use resolved path for headers in decluse diagnostics
Needs ReviewPublic

Authored by kadircet on Jun 7 2021, 2:59 AM.

Details

Reviewers
sammccall
Summary

A header spelling in a source file could potentially mean multiple
sources, especially in projects with multiple include search paths. We
try to eliminate this ambiguity by using the resolved path in the
diagnostics. This should improve the life of both the developers and the
tooling.

Diff Detail

Event Timeline

kadircet requested review of this revision.Jun 7 2021, 2:59 AM
kadircet created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJun 7 2021, 2:59 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
kadircet updated this revision to Diff 350288.Jun 7 2021, 7:45 AM
  • handle windows paths in tests

This seems sensible to me but hard to know if it's going to be an improvement in practice. Can you paste a realistic example?

@rsmith any opinion about this diag?

clang/test/Modules/declare-use1.cpp
6

I'd be tempted to leave the slashes in the globs for readability

It is the absolute path of the header. e.g:

module TestTU does not depend on a module exporting '/work/llvm/clang-tools-extra/clangd/AST.h'

rather than

module TestTU does not depend on a module exporting 'AST.h'

We discussed this a bit offline, and IIUC the plan is not to push this through at least for now. Notes:

  • path to a file is more accurate/informative than spelling, since it really is the file rather than the name that is restricted
  • however in practice the spelling probably isn't ambiguous and is more readable, so this is probably a regression overall for display
  • our motivation here is to be able to unambiguously extract the path programmatically.
    • Adding a struct { string; FileEntry*; } as a diagnostic argument kind is another (somewhat intrusive) way out.
    • The (private) codebase we're experimenting on expresses most #includes relative to a single root, so we can probably just live without this at least for a while
  • If we do this getName() is probably indeed better than tryGetRealPathName, resolving symlinks may have some bad effects