declaration is not visible.

In passing, add a test for a similar case of conflicting redeclarations
of internal-linkage structured bindings. (This case already works).

We were using llvm::SmallPtrSet for our ODR-use set which was also used
for instantiating the implicit lambda captures. The order in which the
captures are added depends on this, so the lambda's layout ended up
changing.  The test just uses floats, but this was noticed with other
types as well.

This test replaces the short-lived SmallPtrSet (it lasts only for an
expression, which, though is a long time for lambdas, is at least not
forever) with a SmallSetVector.

This was originally 658af943 and reverted in 665dbe91.
The clang bug this triggered was fixed in 05ed3efc.

Summary:
DelayedTemplateParsing is marked as BENIGN_LANGOPT, so we are allowed to
use a delayed template in a non-delayed TU.
(This is clangd's default configuration on windows: delayed-template-parsing
is on for the preamble and forced off for the current file)

However today clang fails to parse implicit instantiations in a non-dtp
TU of templates defined in a dtp PCH file (and presumably module?).
In this case the delayed parser is not registered, so the function is
simply marked "delayed" again. We then hit an assert:
end of TU template instantiation should not create more late-parsed templates

Reviewers: rsmith

Subscribers: ilya-biryukov, usaxena95, cfe-commits, kadircet

Tags: #clang

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

Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.

We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.

Reviewed By: sammccall

Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

The thrilling conclusion to the barrage of patches I uploaded lately! This is a
big milestone towards the goal set out in http://lists.llvm.org/pipermail/cfe-dev/2019-August/063070.html.
I hope to accompany this with a patch where the a coreModeling package is added,
from which package diagnostics aren't allowed either, is an implicit dependency
of all checkers, and the core package for the first time can be safely disabled.

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

As reported in PR46111, implicit instantiation of a deduction guide
causes us to have an elaborated type as the parameter, rather than the
dependent type.

After review and feedback from @rsmith, this patch solves this problem
by wrapping the value in an uninstantiated typedef/type-alias that is
instantiated when required later.

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

Checker dependencies were added D54438 to solve a bug where the checker names
were incorrectly registered, for example, InnerPointerChecker would incorrectly
emit diagnostics under the name MallocChecker, or vice versa [1]. Since the
system over the course of about a year matured, our expectations of what a role
of a dependency and a dependent checker should be crystallized a bit more --
D77474 and its summary, as well as a variety of patches in the stack
demonstrates how we try to keep dependencies to play a purely modeling role. In
fact, D78126 outright forbids diagnostics under a dependency checkers name.

These dependencies ensured the registration order and enabling only when all
dependencies are satisfied. This was a very "strong" contract however, that
doesn't fit the dependency added in D79420. As its summary suggests, this
relation is directly in between diagnostics, not modeling -- we'd prefer a more
specific warning over a general one.

To support this, I added a new dependency kind, weak dependencies. These are not
as strict of a contract, they only express a preference in registration order.
If a weak dependency isn't satisfied, the checker may still be enabled, but if
it is, checker registration, and transitively, checker callback evaluation order
is ensured.

If you are not familiar with the TableGen changes, a rather short description
can be found in the summary of D75360. A lengthier one is in D58065.

[1] https://www.youtube.com/watch?v=eqKeqHRAhQM

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

Exactly what it says on the tin! "Strong" dependencies are mentioned in contrast
to a new kind of dependency introduced in a followup patch.

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

[CodeGen] Increase applicability of ffine-grained-bitfield-accesses for targets with limited native integer widths

As pointed out in PR45708, -ffine-grained-bitfield-accesses doesn't
trigger in all cases you think it might for RISC-V. The logic in
CGRecordLowering::accumulateBitFields checks OffsetInRecord is a legal
integer according to the datalayout. RISC targets will typically only
have the native width as a legal integer type so this check will fail
for OffsetInRecord of 8 or 16 when you would expect the transformation
is still worthwhile.

This patch changes the logic to check for an OffsetInRecord of a at
least 1 byte, that fits in a legal integer, and is a power of 2. We
would prefer to query whether native load/store operations are
available, but I don't believe that is possible.

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

Also invert the sense of the return value.

As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate name for this function.

I haven't yet changed any of the strings that are output in
ASTDumper.cpp / JSONNodeDumper.cpp / TextNodeDumper.cpp in response to
whether isHidden() is set because

a) I'm not sure whether it's actually desired to change these strings
   (would appreciate feedback on this), and

b) In any case, I'd like to get this pure rename out of the way first,
   without any changes to tests. Changing the strings that are output in
   the various ...Dumper.cpp files will require changes to quite a few
   tests, and I'd like to make those in a separate change.

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

Reviewed By: rsmith

Rather than pushing inactive cleanups for the block captures at the
entry of a full expression and activating them during the creation of
the block literal, just call pushLifetimeExtendedDestroy to ensure the
cleanups are popped at the end of the scope enclosing the block
expression.

rdar://problem/63996471

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

Functions can have local pragmas that override the global settings.
We set the flags eagerly based on global settings, but if we emit
an expression under the influence of a pragma, we clear the
appropriate flags from the function.

In order to avoid doing a ton of redundant work whenever we emit
an FP expression, configure the IRBuilder to default to global
settings, and only reconfigure it when we see an FP expression
that's not using the global settings.

Patch by Michele Scandale!

https://reviews.llvm.org/D80462

Res is already a ExprResult, so if we call .get(), we will convert an
ExprError() result into an unset result. I discovered this in our downstream
CHERI target where this resulted in a crash due to a NULL-dereference.
It appears that this was introduced in SVN revision 201788 (8690a686)

Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D81608

nodes using the new helper functions introduced
in 78e636b3.

is valid and does not overflow in the bit-field for its storage in more places.
This is a follow-up to 78e636b3. NFC.

These two were missed in 78e636b3.

Added codegen for scan directives in simd loop. The codegen transforms
original code:
```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan inclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <first part>
  x = x_priv + x;
  x_priv = x;
  <second part>
}
```
and
```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan exclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <second part>
  int temp = x;
  x = x_priv + x;
  x_priv = temp;
  <first part>
}
```

Differential revision: https://reviews.llvm.org/D78232

This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
  vtable should be pointers to other structs or relative offsets to those structs.
  Other ABIs can change this enum to restructure how components in the vtable
  are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
  specified position in the aggregate being constructed.
- Fix failing tests under new PM and ASan and MSan issues.

See D72959 for background info.

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

eee944e7 adds the new BuiltinBitCastExpr, but does not set the Code member of
ASTStmtWriter. This is not correct and causes an assertion failue in
ASTStmtWriter::emit() when building PCHs that contain __builtin_bit_cast.  This
commit adds serialization::EXPR_BUILTIN_BIT_CAST and handles
ASTStmtWriter::Code properly.

Differential revision: https://reviews.llvm.org/D80360

This reverts commit fb80e67f to resolve
the issue with asan buildbots.

Summary:
Added codegen for use_device_addr clause. The components of the list
items are mapped as a kind of RETURN components and then the returned
base address is used instead of the real address of the base declaration
used in the use_device_addr expressions.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin

Tags: #clang

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

...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits.

All the information needed to generate these enumerations is already present
in TokenKinds.def. The motivation here is to be able to dump the trait spelling
without hard-coding the list in yet another place.

Note that this change the order of the enumerators in the enumerations (except
that in the TypeTrait enumeration all unary type traits are before all binary
type traits, and all binary type traits are before all n-ary type traits).

Apart from the aforementioned ordering which is relied upon, after this patch
no code in clang or in the various clang tools depend on the specific ordering
of the enumerators.

No functional changes intended.

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

Reviewed By: aaron.ballman

Summary:
This record is constructed by hashing the bytes of the AST block in a similiar
fashion to the SIGNATURE record. This new signature only means anything if the
AST block is fully relocatable, i.e. it does not embed absolute offsets within
the PCM file. This change ensure this does not happen by replacing these offsets
with offsets relative to the nearest relevant subblock of the AST block.

Reviewers: Bigcheese, dexonsmith

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

Added codegen for scandirectives in simd loop. The codegen transforms
original code:

```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan inclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <first part>
  x = x_priv + x;
  x_priv = x;
  <second part>
}
```
and
```
int x = 0;
 #pragma omp simd reduction(inscan, +: x)
for (..) {
  <first part>
  #pragma omp scan exclusive(x)
  <second part>
}
```
into
```
int x = 0;
for (..) {
  int x_priv = 0;
  <second part>
  int temp = x;
  x = x_priv + x;
  x_priv = temp;
  <first part>
}
```

Differential revision: https://reviews.llvm.org/D78232

We're only using the D2 iteration value inside the assert (the only component of the loop) - move the entire loop inside the assert by using llvm::all_of.

...before checking that the default argument is valid with
CheckDefaultArgumentVisitor.

Currently the restrictions on a default argument are checked with the visitor
CheckDefaultArgumentVisitor in ActOnParamDefaultArgument before
performing the conversion to the parameter type in SetParamDefaultArgument.

This was fine before the previous patch but now some valid code post-CWG 2346
is rejected:

void test() {
  const int i2 = 0;
  extern void h2a(int x = i2);     // FIXME: ok, not odr-use
  extern void h2b(int x = i2 + 0); // ok, not odr-use
}

This is because the reference to i2 in h2a has not been marked yet with
NOUR_Constant. i2 is marked NOUR_Constant when the conversion to the parameter
type is done, which is done just after.

The solution is to do the conversion to the parameter type before checking
the restrictions on default arguments with CheckDefaultArgumentVisitor.
This has the side-benefit of improving some diagnostics.

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

Reviewed By: rsmith

[clang] CWG 2082 and 2346: loosen the restrictions on parameters and local variables in default arguments.

This patch implements the resolution of CWG 2082 and CWG 2346.

The resolution of CWG 2082 changed [dcl.fct.default]p7 and p9 to allow
a parameter or local variable to appear in a default argument if not
in a potentially-evaluated expression.

The resolution of CWG 2346 changed [dcl.fct.default]p7 to allow a local
variable to appear in a default argument if not odr-used.

An issue remains after this patch
(see the FIXME in test/CXX/dcl.decl/dcl.meaning/dcl.fct.default/p7.cpp).
This is addressed by the next patch.

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

Reviewed By: rsmith, erichkeane

Before the next patches do the following NFCs:
  - Make it a const visitor; CheckDefaultArgumentVisitor should
    really not modify the visited nodes.

  - clang-format

  - Take a reference to Sema instead of a pointer and pass it
    as the first argument to the constructor. This is for
    consistency with the other similar visitors.

  - Use range for loops when appropriate as per the style guide.

  - Use `const auto *" when appropriate as per the style guide.

Summary:
Introduce on-demand parsing of needed ASTs during CTU analysis.
The index-file format is extended, and analyzer-option CTUInvocationList
is added to specify the exact invocations needed to parse the needed
source-files.

Reviewers: martong, balazske, Szelethus, xazax.hun, whisperity

Reviewed By: martong, xazax.hun

Subscribers: gribozavr2, thakis, ASDenysPetrov, ormris, mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, cfe-commits

Tags: #clang

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

Reviewers: aprantl, dexonsmith, Bigcheese

Subscribers: arphaman, cfe-commits

Tags: #clang

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

The "if (S.getLangOpts().CUDA && Cand1.Function && Cand2.Function) {"
part is known to be problematic but the root cause isn't clear yet.