Reverts llvm/llvm-project#125020https://lab.llvm.org/buildbot/#/builders/24/builds/5252/steps/12/logs/stdio
```
==c-index-test==2512295==ERROR: AddressSanitizer: heap-use-after-free on address 0xe19338c27992 at pc 0xc66be4784830 bp 0xe0e33660df00 sp 0xe0e33660d6e8
READ of size 23 at 0xe19338c27992 thread T1
#0 0xc66be478482c in printf_common(void*, char const*, std::__va_list) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:563:9
#1 0xc66be478643c in vprintf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1699:1
#2 0xc66be478643c in printf /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1757:1
#3 0xc66be4839384 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1359:5
#4 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11
#5 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp
0xe19338c27992 is located 82 bytes inside of 105-byte region [0xe19338c27940,0xe19338c279a9)
freed by thread T1 here:
#0 0xc66be480040c in free /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:51:3
#1 0xc66be4839728 in GetCursorSource c-index-test.c
#2 0xc66be4839368 in FilteredPrintingVisitor /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/c-index-test/c-index-test.c:1360:12
#3 0xe4e3454f12e8 in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CIndex.cpp:227:11
#4 0xe4e3454f48a8 in bool clang::cxcursor::CursorVisitor::visitPreprocessedEntities<clang::PreprocessingRecord::iterator>(clang::PreprocessingRecord::iterator, clang::PreprocessingRecord::iterator, clang::PreprocessingRecord&, clang::FileID) CIndex.cpp
previously allocated by thread T1 here:
#0 0xc66be4800680 in malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3
#1 0xe4e3456379b0 in safe_malloc /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/Support/MemAlloc.h:26:18
#2 0xe4e3456379b0 in createDup /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:95:40
#3 0xe4e3456379b0 in clang::cxstring::createRef(llvm::StringRef) /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/clang/tools/libclang/CXString.cpp:90:10
```
We can't guaranty that underlying string is
0-terminated and [String.size()] is even in the
same allocation.
https://lab.llvm.org/buildbot/#/builders/94/builds/4152/steps/17/logs/stdio
```
==c-index-test==1846256==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 in clang::cxstring::createRef(llvm::StringRef) llvm-project/clang/tools/libclang/CXString.cpp:96:36
#1 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:521:39
#2 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7
#3 in DumpCXCommentInternal llvm-project/clang/tools/c-index-test/c-index-test.c:674:7
#4 in DumpCXComment llvm-project/clang/tools/c-index-test/c-index-test.c:685:3
#5 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:768:7
Memory was marked as uninitialized
#0 in __msan_allocated_memory llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1023:5
#1 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:172:7
#2 in Allocate llvm-project/llvm/include/llvm/Support/Allocator.h:216:12
#3 in Allocate llvm-project/llvm/include/llvm/Support/AllocatorBase.h:53:43
#4 in Allocate<char> llvm-project/llvm/include/llvm/Support/AllocatorBase.h:76:29
#5 in convertCodePointToUTF8 llvm-project/clang/lib/AST/CommentLexer.cpp:42:30
#6 in clang::comments::Lexer::resolveHTMLDecimalCharacterReference(llvm::StringRef) const llvm-project/clang/lib/AST/CommentLexer.cpp:76:10
#7 in clang::comments::Lexer::lexHTMLCharacterReference(clang::comments::Token&) llvm-project/clang/lib/AST/CommentLexer.cpp:615:16
#8 in consumeToken llvm-project/clang/include/clang/AST/CommentParser.h:62:9
#9 in clang::comments::Parser::parseParagraphOrBlockCommand() llvm-project/clang/lib/AST/CommentParser.cpp
#10 in clang::comments::Parser::parseFullComment() llvm-project/clang/lib/AST/CommentParser.cpp:925:22
#11 in clang::RawComment::parse(clang::ASTContext const&, clang::Preprocessor const*, clang::Decl const*) const llvm-project/clang/lib/AST/RawCommentList.cpp:221:12
#12 in clang::ASTContext::getCommentForDecl(clang::Decl const*, clang::Preprocessor const*) const llvm-project/clang/lib/AST/ASTContext.cpp:714:35
#13 in clang_Cursor_getParsedComment llvm-project/clang/tools/libclang/CXComment.cpp:36:35
#14 in PrintCursorComments llvm-project/clang/tools/c-index-test/c-index-test.c:756:25
```
`CXString createRef(StringRef String)` used to return an invalid string when invoked with some empty strings:
If a `StringRef` holds a non-nullptr pointer, for instance, pointing into contents of a larger string, and has a zero length, `createRef` previously returned the entire larger string, ignoring the fact that the actual string passed to it as a param is empty.
This was discovered when invoking `c-index-test` to dump the contents of documentation comments, in case the comment contains an empty HTML attribute, such as `src=""`.
Differential Revision: https://reviews.llvm.org/D133009
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
If the value returned by `malloc`, `calloc` or `realloc` is not checked
for null pointer, this change replaces them for `safe_malloc`,
`safe_calloc` or `safe_realloc`, which are defined in the namespace `llvm`.
These function report fatal error on out of memory.
In the plain C files, assertion statements are added to ensure that memory
is successfully allocated.
The aim of this change is to get better diagnostics of OOM on Windows.
Differential Revision: https://reviews.llvm.org/D43017
llvm-svn: 325661
These are unnecessary, the declarations already carry the 'extern C' property, and if there is mismatch
between declaration and definition then we will get linker errors via libclang.exports.
llvm-svn: 290025
This allows the return of a set of CXStrings from libclang. This is setup work
for an upcoming change to permit returning multiple mangled symbols.
llvm-svn: 252852
These cases in particular were incurring an extra strlen() when we already knew
the length. They appear to be leftovers from when the interfaces worked with C
strings that have continued to compile due to the implicit StringRef ctor.
llvm-svn: 210403
The Container USR's CXString had its underlying data owned by the CXTranslationUnit's string pool. This
would result in trying to access freed memory.
llvm-svn: 137887
but to wrap both an ASTUnit and a "string pool"
that will be used for fast USR generation.
This requires a bunch of mechanical changes, as
there was a ton of code that assumed that CXTranslationUnit
and ASTUnit* were the same.
Along with this change, introduce CXStringBuf,
which provides an llvm::SmallVector<char> backing
for repeatedly generating CXStrings without a huge
amount of malloc() traffic. This requires making
some changes to the representation of CXString
by renaming a few fields (but keeping the size
of the object the same).
llvm-svn: 119337
