clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236400 91177308-0d34-0410-b5e6-96231b3b80d8

These add no value but can make a class non-trivially copyable. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234689 91177308-0d34-0410-b5e6-96231b3b80d8

Should fix the clang-hexagon-elf bot.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223642 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223634 91177308-0d34-0410-b5e6-96231b3b80d8

Otherwise the USR will conflict with different embedded tag decls.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223633 91177308-0d34-0410-b5e6-96231b3b80d8

'class' and 'struct' can be used interchangebly for forward references.
Use the same encoding otherwise we may get into a weird situation where the USR for the same
declaration is different based on whether the definition of the tag reference is visible or not.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223632 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223631 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223630 91177308-0d34-0410-b5e6-96231b3b80d8

[libclang] Reflect in USR generation that 'signed char' and 'unsigned char' can overload a 'char' in C++, by giving them distinct encodings.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223629 91177308-0d34-0410-b5e6-96231b3b80d8

[libclang] Function templates can be 'overloaded' by return type, so encode the return type in the USR
and handle DependentNameType in order to be able to distinguish them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223628 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220893 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220890 91177308-0d34-0410-b5e6-96231b3b80d8

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219000 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  var regex = / a\//; int i;

After:
  var regex = /a\//;
  int i;

This required pushing the Lexer into its wrapper class and generating a
new one in this specific case. Otherwise, the sequence get lexed as a
//-comment. This is hacky, but I don't know a better way (short of
supporting regex literals in the Lexer).

Pushing the Lexer down seems to make all the call sites simpler.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217444 91177308-0d34-0410-b5e6-96231b3b80d8

Overload SourceManager::overrideFileContents so that unconditionally passing ownership is explicitly done using unique_ptr.

Only those callers who are dynamically passing ownership should need the
3 argument form. Those accepting the default ("do pass ownership")
should do so explicitly with a unique_ptr now.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216614 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216585 91177308-0d34-0410-b5e6-96231b3b80d8

Modifications made by clang-tidy with minor tweaks.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215557 91177308-0d34-0410-b5e6-96231b3b80d8

The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.

Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.

Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213171 91177308-0d34-0410-b5e6-96231b3b80d8

Added the pack_elements range accessor. Refactoring some for loops to use range-based for loops instead. No functional changes intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213095 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212369 91177308-0d34-0410-b5e6-96231b3b80d8

This removes a const_cast added in r211884 that occurred due to an
inconsistency in how MemoryBuffers are handled between some parts of
clang and LLVM.

MemoryBuffers are immutable and the general convention in the LLVM
project is to omit const from immutable types as it's simply
redundant/verbose (see llvm::Type, for example). While this change
doesn't remove "const" from /every/ MemoryBuffer, it at least makes this
chain of ownership/usage consistent.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211915 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210403 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209612 91177308-0d34-0410-b5e6-96231b3b80d8

Since the community says that a blacklist is not good enough, and I don't have
enough time now to implement a proper whitelist, let's just remove the
attribute validation.

But, nevertheless, we can still communicate in the generated XML if our parser
found an issue with the HTML.  But this bit is best-effort and is specifically
called out in the schema as such.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207712 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207107 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207087 91177308-0d34-0410-b5e6-96231b3b80d8

The result of llvm::MemoryBuffer::getMemBuffer() needs to be freed. Don't
pass "don't free" flag to overrideFileContents() to fix.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207075 91177308-0d34-0410-b5e6-96231b3b80d8

LSan folks: LSan pointed to
    #0 0x4953e0 in operator new[](unsigned long) llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:64
    #1 0x7fb82af5372f in clang::RewriteRope::MakeRopeString(char const*, char const*) llvm/tools/clang/lib/Rewrite/Core/RewriteRope.cpp:796
instead of to the actual leak, which made tracking this down slower than
it could have been.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207031 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206886 91177308-0d34-0410-b5e6-96231b3b80d8

through to the output even if the input comment comes from an untrusted source

Attribute filtering is currently based on a blacklist, which right now includes
all event handler attributes (they contain JavaScipt code).  It should be
switched to a whitelist, but going over all of the HTML5 spec requires a
significant amount of time.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206882 91177308-0d34-0410-b5e6-96231b3b80d8

unless the macro comes from a system header


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205064 91177308-0d34-0410-b5e6-96231b3b80d8

found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.

 ARCMigrate/TransProperties.cpp                  |    8 -----
 AST/MicrosoftMangle.cpp                         |    1 
 Analysis/AnalysisDeclContext.cpp                |    5 ---
 Analysis/LiveVariables.cpp                      |   14 ----------
 Index/USRGeneration.cpp                         |   10 -------
 Sema/Sema.cpp                                   |   33 +++++++++++++++++++++---
 Sema/SemaChecking.cpp                           |    3 --
 Sema/SemaDecl.cpp                               |   20 ++------------
 StaticAnalyzer/Checkers/GenericTaintChecker.cpp |    1 
 9 files changed, 34 insertions(+), 61 deletions(-)


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204561 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replacing FunctionProtoType iterators param_type_begin() and param_type_end() with iterator_range param_types(). Updating all of the usages of the iterators with range-based for loops.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204045 91177308-0d34-0410-b5e6-96231b3b80d8

[C++11] Replacing FunctionDecl iterators param_begin() and param_end() with iterator_range params(). Updating all of the usages of the iterators with range-based for loops.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203248 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202238 91177308-0d34-0410-b5e6-96231b3b80d8

- Only include offsets with local (in function scope) symbols, where we don't encode scoping
- Only include the filename with non-system symbols. Presumably the system headers will not provide conflicting definitions.

rdar://15976823

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201990 91177308-0d34-0410-b5e6-96231b3b80d8

A return type is the declared or deduced part of the function type specified in
the declaration.

A result type is the (potentially adjusted) type of the value of an expression
that calls the function.

Rule of thumb:

  * Declarations have return types and parameters.
  * Expressions have result types and arguments.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.

Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.

Will keep an eye on the builders and update dependent projects shortly.

No functional change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199640 91177308-0d34-0410-b5e6-96231b3b80d8

encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198686 91177308-0d34-0410-b5e6-96231b3b80d8