Merge llvm-project release/18.x llvmorg-18.1.1-0-gdba2a75e9c7e

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/18.x llvmorg-18.1.1-0-gdba2a75e9c7e.

PR: 276104
MFC after: 1 month

Merge llvm-project main llvmorg-18-init-18359-g93248729cfae

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-18359-g93248729cfae, the
last commit before the upstream release/18.x branch was created.

PR: 276104
MFC after: 1 month

Merge llvm-project main llvmorg-18-init-16864-g3b3ee1f53424

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-16864-g3b3ee1f53424.

PR: 276104
MFC after: 1 month

Merge llvm-project main llvmorg-18-init-16595-g7c00a5be5cde

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-16595-g7c00a5be5cde.

PR: 276104
MFC after: 1 month

Merge llvm-project main llvmorg-18-init-15692-g007ed0dccd6a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-15692-g007ed0dccd6a.

PR: 276104
MFC after: 1 month

Merge llvm-project main llvmorg-18-init-15088-gd14ee76181fb

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-15088-gd14ee76181fb.

PR: 276104
MFC after: 1 month

Merge commit 158f4f30adb4 from llvm git (by Corentin Jabot):

[Clang] Do not change the type of captured vars when checking lambda constraints

When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.

In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.

Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.

There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.

Fixes #61267

Reviewed By: aaron.ballman, #clang-language-wg

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

Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):

[Clang] Add captures to the instantiation scope of lambda call operators

Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.

This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.

`*this` (like all captures) only become `const`
after the parameter list.

However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).

There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.

Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.

Fixes #65067
Fixes #63675

Reviewed By: erichkeane

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

This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
instantiated in this scope"), function findInstantiationOf' error when
building databases/mongodb44.

PR: 273753
MFC after: 1 month

Merge llvm-project release/17.x llvmorg-17.0.5-0-g98bfdac5ce82

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-17.0.5-0-g98bfdac5ce82.

PR: 273753
MFC after: 1 month

Merge llvm-project release/17.x llvmorg-17.0.0-rc4-10-g0176e8729ea4

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-17.0.0-rc4-10-g0176e8729ea4.

PR: 273753
MFC after: 1 month

Merge llvm-project main llvmorg-17-init-19304-gd0b54bb50e51

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the
last commit before the upstream release/17.x branch was created.

PR: 273753
MFC after: 1 month

Merge llvm-project release/16.x llvmorg-16.0.1-0-gcd89023f7979

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.1-0-gcd89023f7979 (aka 16.0.1 release).

PR: 271047
MFC after: 1 month

Merge llvm-project main llvmorg-16-init-18548-gb0daacf58f41

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16-init-18548-gb0daacf58f41.

PR: 271047
MFC after: 1 month

Apply clang fix for assertion building emulators/rpcs3

Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):

[clang] Fix crash when handling nested immediate invocations

Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}

channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.

This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.

Fixes https://github.com/llvm/llvm-project/issues/58207

Reviewed By: aaron.ballman, shafik

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

PR: 269489
MFC after: 3 days

Merge llvm-project release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-rc2-40-gfbd2950d8d0d.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17826-g1f8ae9d7e7e4

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17485-ga3e38b4a206b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17485-ga3e38b4a206b.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-16436-g18a6ab5b8d1f

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-16436-g18a6ab5b8d1f.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-17616-g024a1fab5c35

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-13186-g0c553cc1af2e

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-11187-g222442ec2d71

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR: 261742
MFC after: 2 weeks

Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project 12.0.0 release

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR: 255570
MFC after: 6 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.

Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251
MFC after: 6 weeks

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions.

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update
build glue.

Merge ^/vendor/lvm-project/release-10.x up to its last change (upstream
commit llvmorg-10-init-17538-gd11abddb32f).

Merge ^/vendor/lvm-project/master up to its last change (upstream commit
e26a78e70), and resolve conflicts.

Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Merge commit 158f4f30adb4 from llvm git (by Corentin Jabot):

[Clang] Do not change the type of captured vars when checking lambda constraints

When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.

In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.

Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.

There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.

Fixes #61267

Reviewed By: aaron.ballman, #clang-language-wg

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

Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):

[Clang] Add captures to the instantiation scope of lambda call operators

Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.

This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.

`*this` (like all captures) only become `const`
after the parameter list.

However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).

There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.

Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.

Fixes #65067
Fixes #63675

Reviewed By: erichkeane

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

This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
instantiated in this scope"), function findInstantiationOf' error when
building databases/mongodb44.

PR: 273753
MFC after: 1 month

Merge llvm-project release/16.x llvmorg-16.0.1-0-gcd89023f7979

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.1-0-gcd89023f7979 (aka 16.0.1 release).

PR: 271047
MFC after: 1 month

Merge llvm-project main llvmorg-16-init-18548-gb0daacf58f41

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16-init-18548-gb0daacf58f41.

PR: 271047
MFC after: 1 month

Apply clang fix for assertion building emulators/rpcs3

Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):

[clang] Fix crash when handling nested immediate invocations

Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}

channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.

This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.

Fixes https://github.com/llvm/llvm-project/issues/58207

Reviewed By: aaron.ballman, shafik

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

PR: 269489
MFC after: 3 days

Merge llvm-project release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-rc2-40-gfbd2950d8d0d.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17826-g1f8ae9d7e7e4

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17485-ga3e38b4a206b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17485-ga3e38b4a206b.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-16436-g18a6ab5b8d1f

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-16436-g18a6ab5b8d1f.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-17616-g024a1fab5c35

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-13186-g0c553cc1af2e

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-11187-g222442ec2d71

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR: 261742
MFC after: 2 weeks

Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project 12.0.0 release

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR: 255570
MFC after: 6 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.

Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251
MFC after: 6 weeks

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions.

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update
build glue.

Merge ^/vendor/lvm-project/release-10.x up to its last change (upstream
commit llvmorg-10-init-17538-gd11abddb32f).

Merge ^/vendor/lvm-project/master up to its last change (upstream commit
e26a78e70), and resolve conflicts.

Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Apply clang fix for assertion building emulators/rpcs3

Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):

[clang] Fix crash when handling nested immediate invocations

Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}

channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.

This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.

Fixes https://github.com/llvm/llvm-project/issues/58207

Reviewed By: aaron.ballman, shafik

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

PR: 269489
MFC after: 3 days

Merge llvm-project release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-rc2-40-gfbd2950d8d0d.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17826-g1f8ae9d7e7e4

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-17485-ga3e38b4a206b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17485-ga3e38b4a206b.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-16436-g18a6ab5b8d1f

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-16436-g18a6ab5b8d1f.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-17616-g024a1fab5c35

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-13186-g0c553cc1af2e

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-11187-g222442ec2d71

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR: 261742
MFC after: 2 weeks

Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project 12.0.0 release

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR: 255570
MFC after: 6 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.

Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251
MFC after: 6 weeks

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions.

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update
build glue.

Merge ^/vendor/lvm-project/release-10.x up to its last change (upstream
commit llvmorg-10-init-17538-gd11abddb32f).

Merge ^/vendor/lvm-project/master up to its last change (upstream commit
e26a78e70), and resolve conflicts.

Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Merge llvm-project main llvmorg-14-init-17616-g024a1fab5c35

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-13186-g0c553cc1af2e

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-11187-g222442ec2d71

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR: 261742
MFC after: 2 weeks

Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project 12.0.0 release

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR: 255570
MFC after: 6 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.

Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251
MFC after: 6 weeks

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions.

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update
build glue.

Merge ^/vendor/lvm-project/release-10.x up to its last change (upstream
commit llvmorg-10-init-17538-gd11abddb32f).

Merge ^/vendor/lvm-project/master up to its last change (upstream commit
e26a78e70), and resolve conflicts.

Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Merge llvm-project release/13.x llvmorg-13.0.0-rc1-97-g23ba3732246a

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13.0.0-rc1-97-g23ba3732246a.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project 12.0.0 release

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12.0.0-0-gd28af7c654d8, a.k.a. 12.0.0 release.

PR: 255570
MFC after: 6 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.

Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251
MFC after: 6 weeks

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc3-1-gc290cb61fdc), and bump versions.

Merge ^/vendor/llvm-project/release-10.x up to its last change (upstream
commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update
build glue.

Merge ^/vendor/lvm-project/release-10.x up to its last change (upstream
commit llvmorg-10-init-17538-gd11abddb32f).

Merge ^/vendor/lvm-project/master up to its last change (upstream commit
e26a78e70), and resolve conflicts.

Merge ^/vendor/clang/dist up to its last change, and resolve conflicts.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Fix clang assertion when compiling the devel/onetbb port

Merge commit 740a164de from llvm git (by Richard Smith):

PR46377: Fix dependence calculation for function types and typedef
types.

We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.

We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.

Merge commit 9cf98d26e from llvm git (by Richard Smith):

PR46637: Fix handling of placeholder types in trailing-return-types.

Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.

Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.

Merge commit 234f51a65 from llvm git (by Richard Smith):

Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.

Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

PR: 252892
Reported by: thierry
MFC after: 3 days

Merge commit e09107ab8 from llvm git (by Raul Tambre):

[Sema] Introduce BuiltinAttr, per-declaration builtin-ness

Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.

This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.

Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.

Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.

A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.

Fixes PR45410.

Reviewed By: rsmith, yutsumi

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

This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.

Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.

Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.