PeterChou1 wrote:
Ok nevermind, disregard the above comment I was wrong about the mechanism of
the bug.
the source of this bug comes from the way clang-doc handles C code,
particularly anonymous typedef in C. When clang-doc encounters an anonymous
typedef in C it incorrectly serializes its a name as a simple example running
clang-doc on this file
test.c
```
/**
* Foo anon typedef
*/
typedef struct {} Foo;
```
running this file with clang-doc will interpret Foo as @nonymous_record_XXXXXXX.
The reason why that is because when checking anonymous typedef name we're
explicitly casting it to a CXXDecl see code
[here](https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clang-doc/Serialize.cpp#L664).
This becomes a problem when we run the LLVM compilation database. As an example
a record that we were not properly serializing before was
LLVMOrcCDependenceMapPair. When clang-doc runs the compilation database of LLVM
it encounters code running under example code OrcV2CBindingsRemovableCode.c.
This file causes recursiveASTVisitor to visit LLVMOrcCDependenceMapPair but
because its c code its name is not found and it is incorrectly serialized into
@nonymous_record_XXXXX.
Normally this is not an issue for clang-doc since we'll visit the record
multiple times and the next time we visit it clang-doc will correctly fill in
the name of the declaration.
But this patch changes that behaviour since we're only visiting the a typedef
declaration at most once
we now incorrectly serialized what was LLVMOrcCDependenceMapPair to
@nonymous_record_XXXXX
https://github.com/llvm/llvm-project/pull/96809
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
