r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015
rejects-valid.

Original commit message:

[modules] Rework serialized DeclContext lookup table management. Instead of
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.

This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).


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

Reverting r246497 (which requires also reverting r246524 and r246521 to avoid merge conflicts). It broke the build on MSVC 2015. It also broke an MSVC 2013 bot with testing issues.

llvm\tools\clang\lib\serialization\MultiOnDiskHashTable.h(117):
error C2065: 'Files': undeclared identifier

http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/2917

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

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

walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.

This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).


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

DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in the type used as the lookup table key. As a side-effect, remove
one copy of the duplicated code used to compute the hash of the key.


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

Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0).
Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions.
Differential Revision: http://reviews.llvm.org/D10732


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

Instead of eagerly deserializing a list of DeclIDs when we load a module file
and doing a binary search to find the redeclarations of a decl, store a list of
redeclarations of each chain before the first declaration and load it directly.


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

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

DeclContext. These only ever come from the owning module file for the Decl.


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

chain and fix the cases where it fires.

 * Handle the __va_list_tag as a predefined decl. Previously we failed to merge
   sometimes it because it's not visible to name lookup. (In passing, remove
   redundant __va_list_tag typedefs that we were creating for some ABIs. These
   didn't affect the mangling or representation of the type.)

 * For Decls derived from Redeclarable that are not in fact redeclarable
   (implicit params, function params, ObjC type parameters), remove them from
   the list of expected redeclarable decls.


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

[modules] Stop performing PCM lookups for all identifiers when building with C++ modules. Instead, serialize a list of interesting identifiers and mark those ones out of date on module import. Avoiding the identifier lookups here gives a 20-30% speedup in builds with large numbers of modules. No functionality change intended.


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

for OpenMP 4 target data directive parsing and sema.
This commit is on behalf of Kelvin Li.

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

Produce type parameter declarations for Objective-C type parameters,
and attach lists of type parameters to Objective-C classes,
categories, forward declarations, and extensions as
appropriate. Perform semantic analysis of type bounds for type
parameters, both in isolation and across classes/categories/extensions
to ensure consistency.

Also handle (de-)serialization of Objective-C type parameter lists,
along with sundry other things one must do to add a new declaration to
Clang.

Note that Objective-C type parameters are typedef name declarations,
like typedefs and C++11 type aliases, in support of type erasure.

Part of rdar://problem/6294649.

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

Implemented parsing/sema analysis + (de)serialization.


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

Add parsing and sema analysis for 'omp cancellation point' directive.


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

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

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



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

Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0).
The code for directive is generated the following way:
#pragma omp taskgroup
<body>

void __kmpc_taskgroup(<loc>, thread_id);
<body>
void __kmpc_end_taskgroup(<loc>, thread_id);


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

Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm

This patch attempts to fix this problem.

Given the following code snippet,

struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };

struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
//   whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };


Differential Review: http://reviews.llvm.org/D5789



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

Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.

rev 2 update:
`getNewExprFromInitListOrExpr` should return `dyn_cast_or_null`
instead of `dyn_cast`, since `E` might be null.

Reviewers: rtrieu, jordan_rose, rsmith

Subscribers: majnemer, cfe-commits

Differential Revision: http://reviews.llvm.org/D4661

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

This reverts commit 742dc9b6.

This is generating multiple segfaults in our internal builds.
Test case coming up shortly.

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

Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.

Reviewers: rtrieu, jordan_rose, rsmith

Subscribers: majnemer, cfe-commits

Differential Revision: http://reviews.llvm.org/D4661

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

[modules] Move list of exported module macros from IdentifierInfo lookup table to separate storage, adjacent to the macro directive history.

This is substantially simpler, provides better space usage accounting in bcanalyzer,
and gives a more compact representation. No functionality change intended.


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

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

Previously we'd deserialize the list of mem-initializers for a constructor when
we deserialized the declaration of the constructor. That could trigger a
significant amount of unnecessary work (pulling in all base classes
recursively, for a start) and was causing problems for the modules buildbot due
to cyclic deserializations. We now deserialize these on demand.

This creates a certain amount of duplication with the handling of
CXXBaseSpecifiers; I'll look into reducing that next.


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

consumers of that module.

Previously, such a file would only be available if the module happened to
actually import something from that module.


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

of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).

No functionality change intended.


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

We used to save out and eagerly load a (potentially huge) table of merged
formerly-canonical declarations when we loaded each module. This was extremely
inefficient in the presence of large amounts of merging, and didn't actually
save any merging lookup work, because we still needed to perform name lookup to
check that our merged declaration lists were complete. This also resulted in a
loss of laziness -- even if we only needed an early declaration of an entity, we
would eagerly pull in all declarations that had been merged into it regardless.

We now store the relevant fragments of the table within the declarations
themselves. In detail:

 * The first declaration of each entity within a module stores a list of first
   declarations from imported modules that are merged into it.
 * Loading that declaration pre-loads those other entities, so that they appear
   earlier within the redeclaration chain.
 * The name lookup tables list the most recent local lookup result, if there
   is one, or all directly-imported lookup results if not.


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

dynamic classes in the translation unit and check whether each one's key
function is defined when we got to the end of the TU (and when we got to the
end of each module). This is really terrible for modules performance, since it
causes unnecessary deserialization of every dynamic class in every compilation.

We now use a much simpler (and, in a modules build, vastly more efficient)
system: when we see an out-of-line definition of a virtual function, we check
whether that function was in fact its class's key function. (If so, we need to
emit the vtable.)


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

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

This fixes PR21587, what r221933 fixed for regular programs is now also
fixed for decls coming from PCH files.

Use another bit from the count/bits uint16_t for storing the "more than one
decl" bit.  This reduces the number of bits for the count from 14 to 13.
The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits
should still be plenty.  Since this changes the meaning of a serialized bit
pattern, also increase clang::serialization::VERSION_MAJOR.

Storing the "more than one decl" state of only the first overload isn't quite
correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at
the state of the first overload so it's good enough for now.


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

the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.

This is a recommit of r223443, reverted in r223465; when joining together
imported file paths, we now use the system's separator rather than always
using '/'. This avoids path mismatches between the original module build and
the module user on Windows (at least, in some cases). A more comprehensive
fix will follow.


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

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

the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.


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

This is a new form of expression of the form:

  (expr op ... op expr)

where one of the exprs is a parameter pack. It expands into

  (expr1 op (expr2onwards op ... op expr))

(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.


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

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

Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.

To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.

This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.

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

This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.


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

Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive.  


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

Revert "[OPENMP] 'omp teams' directive basic support. Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive."

This reverts commit r219197 because it broke ARM self-hosting buildbots with
segmentation fault errors in many tests.

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