And what it’s output format is?
I can run it without error from the command line, but codechecker seems to do something strange with it and it then fails to find header files.
And what it’s output format is?
I can run it without error from the command line, but codechecker seems to do something strange with it and it then fails to find header files.
the extdefmap (aka. external definition mapping) is supposed to list all external linkage symbols (decls) to a file path where it gets defined.
Decls are identified by USRs - which you can think of as a special name mangling to get unique but deterministic “hashes” or “names” for the external symbols (They are mostly free of whitespaces, but actually they can contain spaces.)
Inside the clang/include/clang/Basic/DiagnosticCrossTUKinds.td
file you can see the error diagnostics for CTU stuff, including if a line of the extdefmapping file could not be parsed:
def err_extdefmap_parsing : Error<
"error parsing index file: '%0' line: %1 '<USR-Length>:<USR> <File-Path>' "
"format expected">;
USRs are generated for decls, by bool clang::index::generateUSRForDecl(const Decl *D, SmallVectorImpl<char> &Buf);
, declared in clang/include/clang/Index/USRGeneration.h
.
For the CTU analysis logic, I’d suggest reading clang/lib/CrossTU/CrossTranslationUnit.cpp
, ensureCTUIndexLoaded()
, and parseCrossTUIndex()
functions.
And to answer your question, well we probably don’t have documentation for it.
Thanks, I note that it doesn’t (as at clang-extdef-mapping-14) emit any information about whether the symbol is weak or strong.
Which I think is causing my problems downstream with CTU spewing lots “error: multiple definitions are found for the same key in index” messages.
Do you know if this is a known bug or limitation? My google fu failed to mention of it.