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

Recommitted after formal approval.

LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project.

Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault.

Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code.

I propose that the parts required to build a simple expression parser be added to Clang. Initially, I aim to have the following features:

A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests.
A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside.
This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter. When complete, this tester will implement the first of the above goals.

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


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

program

Offload related code is not quite ready yet, but some simple examples
must not crash the compiler. Patch fixes the problem in offloading code
with exceptions.

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

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

I don't remember why I didn't make alloc_size only applicable to
Functions a year ago, but I can't see any compelling reason not to do
so now.

Fixes PR31453.


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

Update the GTestChecker to tighten up the API detection and make it
cleaner in response to post-commit feedback. Also add tests for when
temporary destructors are enabled to make sure we get the expected behavior
when inlining constructors for temporaries.

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

Warnings with suppress-on-sink are discarded during FlushReports when
BugReporter notices that all paths in ExplodedGraph that pass through the
warning eventually run into a sink node.

However, suppress-on-sink fails to filter out false positives when the analysis
terminates too early - by running into analyzer limits, such as block count
limits or graph size limits - and the interruption hits the narrow window
between throwing the leak report and reaching the no-return function call. In
such case the report is there, however suppression-on-sink doesn't work, because
the sink node was never constructed in the incomplete ExplodedGraph.

This patch implements a very partial solution: also suppress reports thrown
against a statement-node that corresponds to a statement that belongs to a
no-return block of the CFG.

rdar://problem/28832541

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


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

Before:
  string v =
      StrCat("aaaaaaaaaaaaaaaaaaaaaaaaaaa: ", SomeFunction(aaaaaaaaaaaa,
                                                           aaaaaaaaaaaaaaa),
             bbbbbbbbbbbbbbbbbbbbbbb);

After:
  string v = StrCat("aaaaaaaaaaaaaaaaaaaaaaaaaaa: ",
                    SomeFunction(aaaaaaaaaaaa, aaaaaaaaaaaaaaa),
                    bbbbbbbbbbbbbbbbbbbbbbb);

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

the bots unhappy.


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

Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs
overlay provided by the crash reproducer. This is the last missing piece
to allow crash reproducers to fully work with user frameworks; when
combined with headermaps, it allows clang to find additional frameworks.

rdar://problem/27913709

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

Modify getStyle to use vfs::FileSystem::makeAbsolute just like FS.addFile does,
rather than sys::fs::make_absolute. The latter gets the CWD from the platform,
while the former expects it to be set by the client, causing a mismatch when
converting relative paths to absolute.

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

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

Print the fully qualified names for the overload candidates.  This makes
it easier to tell what the ambiguity is.  Especially if a template
is instantiated after a using namespace, it will not inherit the
namespace where it was declared.  The specialization will give a message
about a partial order being ambiguous for the same (unqualified) name,
which does not help identify the failure.

Addresses PR31450!

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

twice, in finalization of template argumetn deduction.


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

Although the result is the same, the intent is much more clear this way:
we care about the architecture we are targeting.  NFC.

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

We can query the Triple and EffectiveTriple from the ToolChain.  Avoid
passing in the argument and query it in the function.  NFC.

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

The parameter to ParsePICOpts passed the effective triple and then used
that in a few places and used the actual triple in others.  This was
slightly confusing.  Rename the parameter to make it more obvious.

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

This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.

Fingers crossed that this patch sticks this time. :)

Original commit message:

This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
  number of bytes handed back to us by malloc/realloc/calloc/any user
  functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
  is OK sometimes. This is why we have a change in
  test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
  unrelated tests. Richard Smith okay'ed this idea some time ago in
  person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
  D26410. Lack of uniquing only really shows up as a problem when
  combined with our new eagerness in the face of const.


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

argument even if the expression is value-dependent (we need to suppress the
final portion of the narrowing check, but the rest of the checking can still be
done eagerly).

This affects template template argument validity and partial ordering under
p0522r0.


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

FPv5 is in Cortex-M7 and the 64-bit CPUs when running in 32-bit mode. The name
is from the Cortex-M7 TRM.

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

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


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

Members that are themselves wrapped in fake parentheses would lead to
AvoidBinPacking be set on the wrong ParenState.

After:
  vector<int> aaaa = {
      aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
      aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
      aaaaaa.aaaaaaa,
      aaaaaa.aaaaaaa,
      aaaaaa.aaaaaaa,
      aaaaaa.aaaaaaa,
  };

Before we were falling back to bin-packing these.

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

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

Summary:
This follows up to r290217, and makes functions on ASTRecordReader consistent
and valid style.

Reviewers: rsmith

Subscribers: cfe-commits

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

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

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

effect they would have in C++11. In particular, they do not prevent
value-initialization from performing zero-initialization, nor do they prevent a
struct from being an aggregate.


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

the requested cv-qualifiers after construction. This usually doesn't matter,
but it does matter within a ?: operator.


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

function. (This change would also allow us to handle default template arguments
in partial specializations if the standard ever permits them.)


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

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

Summary:
The module system supports accompanying a primary module (say Foo) with
an auxiliary "private" module (defined in an adjacent module.private.modulemap
file) that augments the primary module when associated private headers are
available. The feature is intended to be used to augment the primary
module with a submodule (say Foo.Private), however some users in the wild
are choosing to augment the primary module with an additional top-level module
with a "similar" name (in all cases so far: FooPrivate).

This "works" when a user of the module initially imports a private header,
such as '#import "Foo/something_private.h"' since the Foo import winds up
importing FooPrivate in passing. But if the import is subsequently recorded
in a PCH file, reloading the PCH will fail to validate because of a cross-check
that attempts to find the module.modulemap (or module.private.modulemap) using
HeaderSearch algorithm, applied to the "FooPrivate" name. Since it's stored in
Foo.framework/Modules, not FooPrivate.framework/Modules, the check fails and
the PCH is rejected.

This patch adds a compensatory workaround in the HeaderSearch algorithm
when searching (and failing to find) a module of the form FooPrivate: the
name used to derive filesystem paths is decoupled from the module name
being searched for, and if the initial search fails and the module is
named "FooPrivate", the filesystem search name is altered to remove the
"Private" suffix, and the algorithm is run a second time (still looking for
a module named FooPrivate, but looking in directories derived from Foo).

Accompanying this change is a new warning that triggers when a user loads
a module.private.modulemap that defines a top-level module with a different
name from the top-level module defined in its adjacent module.modulemap.

Reviewers: doug.gregor, manmanren, bruno

Subscribers: bruno, cfe-commits

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

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

Summary:
For ASTDeclReader and ASTStmtReader, every parameter "unsigned &Idx" ultimately
comes from a variable that is defined on the stack, next to the RecordData. This
change moves that index into the ASTRecordReader.

TypeLocReader cannot be transitioned, due to TableGen-generated code which calls
ASTReader::GetTypeSourceInfo.

Reviewers: rsmith

Subscribers: cfe-commits

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

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

In stack-reuse-miscompile.cpp, the allocas for the temps come out in
a different order depending on whether the dialect is C++03 or
C++11. Specify C++03 explicitly to avoid depending on the default.

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


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

If a dtor has no interesting members, then it ends up being nothrow,
which affects the generated IR. Modify some tests to tolerate this
difference between C++03 and C++11.

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


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

In C++11 we don't emit vtables as eagerly as we do for C++03, so
fiddle the tests to emit them when the test expects them.

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


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

This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.

This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.


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

based coverage compilation

Added source location info to captured expression declaration + fixed
source location info for loop based directives.

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

While for <<-operators often used in log statments, a single key value
pair is always on the second operator, e.g.

  llvm::errs() << "aaaaa=" << aaaaa;

It is on the first operator for plus- or comma-concatenated strings:

  string s = "aaaaaaaaaa: " + aaaaaaaa;

(the "=" not counting because that's a different operator precedence)

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

Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5
and higher + in OpenMP 4.5 parsing procedure emits error message if ':'
is not found after directive name modifier.

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

This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.

Replied on the commit with more details.

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

Summary:
Fixes spelling name ranges for user-defined string literal operators.

Example:
  constexpr int operator""_toint(unsigned long long val)
  { return int(val); }

Before this patch the spelling name range on consisted of 'operator'.

After this patch: 'operator""_toint'.

Related to http://reviews.llvm.org/D5041, which fixes the function for
other cursor kinds.

Reviewers: akyrtzi, craigt, skalinichev, klimek, milianw, bkramer

Subscribers: cfe-commits

Tags: #clang-c

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

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

Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.

Reviewers: Anastasia

Subscribers: cfe-commits, yaxunl, bader

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

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