Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Clean up use of C allocation functions

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_r

Clean up use of C allocation functions

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

show more ...

[libclang] Remove the 'extern "C"' blocks from the implementation files.

These are unnecessary, the declarations already carry the 'extern C' property, and if there is mismatch
between declaration a

[libclang] Remove the 'extern "C"' blocks from the implementation files.

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

show more ...

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

Differential Revision: https://reviews.llvm.org/D20

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

Differential Revision: https://reviews.llvm.org/D20100

llvm-svn: 275882

show more ...

Try to fix leak in CXStringSet from r252853

llvm-svn: 253418

libclang: add new StringSet type

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

[C++11] Use 'nullptr'. Tools edition.

llvm-svn: 210422

Avoid dubious IdentifierInfo::getNameStart() uses

These cases in particular were incurring an extra strlen() when we already knew
the length. They appear to be leftovers from when the interfaces wor

Avoid dubious IdentifierInfo::getNameStart() uses

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

show more ...

libclang: wrap CXString implementation into 'namespace cxstring'

This removes quite a few 'cxstring::' qualifications where they are obvious.

llvm-svn: 174286

libclang: introduce cxstring::{createRef,createDup} for StringRefs

Also migrate all clients from the old API.

llvm-svn: 174263

libclang: introduce cxstring::{createRef,createDup} for C strings

Also migrate all clients from the old API.

llvm-svn: 174238

libclang: add comments for CXStringFlag

llvm-svn: 174194

libclang: itroduce cxstring::createEmpty()

llvm-svn: 174174

libclang: introduce cxstring::createNull()

llvm-svn: 174173

libclang: refactor CXStringPool: make it a class

We are not exposing the pool or string buffers to libclang users, so no need to
maintain a procedural interface.

llvm-svn: 173595

libclang: use C++ casts in CXString.cpp

llvm-svn: 172272

libclang: constness for CXString

llvm-svn: 172270

Sort #include lines for tools/...

Completely automated with sort_includes.py

llvm-svn: 169240

[libclang] Workaround potential race condition with code completion AllocatedResults being freed after a CXTranslationUnit.

The Container USR's CXString had its underlying data owned by the CXTransl

[libclang] Workaround potential race condition with code completion AllocatedResults being freed after a CXTranslationUnit.

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

show more ...

remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.

llvm-svn: 135852

Make definition of CXTranslationUnitImpl private
to libclang.

llvm-svn: 119585

Change CXTranslationUnit to not directly cast to an ASTUnit*,
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,

Change CXTranslationUnit to not directly cast to an ASTUnit*,
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

show more ...

Add CXString.cpp and CXString.h

llvm-svn: 119322