| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Clang][NFCI] Cleanup the fix for default function argument substitution (#104911)
(This is one step towards tweaking `getTemplateInstantiationArgs()` as
discussed in https://github.com/llvm/llvm-project/pull/102922)
We don't always substitute into default arguments while transforming a
function parameter. In that case, we would preserve the uninstantiated
expression until after, e.g. building up a CXXDefaultArgExpr and
instantiate the expression there.
For member function instantiation, this algorithm used to cause a
problem in that the default argument of an out-of-line member function
specialization couldn't get properly instantiated. This is because, in
`getTemplateInstantiationArgs()`, we would give up visiting a function's
declaration context if the function is a specialization of a member
template. For example,
```cpp
template <class T>
struct S {
template <class U>
void f(T = sizeof(T));
};
template <> template <class U>
void S<int>::f(int) {}
```
The default argument `sizeof(U)` that lexically appears inside the
declaration would be copied to the function declaration in the class
template specialization `S<int>`, as well as to the function's
out-of-line definition. We use template arguments collected from the
out-of-line function definition when substituting into the default
arguments. We would therefore give up the traversal after the function,
resulting in a single-level template argument of the `f` itself. However
the default argument here could still reference the template parameters
of the primary template, hence the error.
In fact, this is similar to constraint checking in some respects: we
actually want the "whole" template arguments relative to the primary
template, not those relative to the function definition. So this patch
adds another flag to indicate `getTemplateInstantiationArgs()` for that.
This patch also consolidates the tests for default arguments and removes
some unnecessary tests.
This fixes a crash or assertion failure while building tests for the
devel/hpx port.
PR: 288352
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang++ may crash when compiling certain C++20 modules. Backport the
fix from LLVM upstream.
This fixes LLVM bug 102684:
https://github.com/llvm/llvm-project/issues/102684.
PR: 287803
MFC after: 3 days
Obtained from: https://github.com/llvm/llvm-project/pull/102855
Reviewed by: kevans, dim
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D51041
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.4-0-gaadaa00de76e,
a.k.a. 19.1.4 release.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.3-0-gab51eccf88f5,
a.k.a. 19.1.3 release.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6,
a.k.a. 19.1.2 release.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349,
a.k.a. 19.1.1 release.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-19-init-18630-gf2ccf80136a0, the
last commit before the upstream release/19.x branch was created.
PR: 280562
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/18.x llvmorg-18.1.4-0-ge6c3289804a6.
PR: 276104
MFC after: 3 days
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/18.x llvmorg-18.1.3-0-gc13b7485b879.
PR: 276104
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/18.x llvmorg-18.1.0-rc2-53-gc7b0a6ecd442.
PR: 276104
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project release/18.x llvmorg-18.1.0-rc2-0-gc6c86965d967.
PR: 276104
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-16003-gfc5f51cf5af4.
PR: 276104
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-17.0.6-0-g6009708b4367.
PR: 273753
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-17.0.1-25-g098e653a5bed.
PR: 273753
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Clang] Show type in enum out of range diagnostic
When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:
v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^
This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152788
PR: 271047
MFC after: 1 month
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.5-0-g185b81e034ba (aka 16.0.5 release).
PR: 271047
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies upstream commit c0141f3c300f by Aaron Ballman:
Downgrade implicit int and implicit function declaration to warning only
The changes in Clang 15.0.0 which enabled these diagnostics as a
warning which defaulted to an error caused disruption for people
working on distributions such as Gentoo. There was an explicit request
to downgrade these to be warning-only in Clang 15.0.1 with the
expectation that Clang 16 will default the diagnostics to an error.
See
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
for more details on the discussion.
See https://reviews.llvm.org/D133800 for the public review of these
changes.
As noted in the upstream discussion, there are many programs that fail
to configure or build correctly, if these warnings are turned into
errors by default.
Note that most affected programs in ports are relatively old, and are
unlikely to be fixed by actually adjusting their declarations, but by
compiling with -std=gnu89, which downgrades the errors back to warning
again. Lots of tedious work for very little gain.
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16-init-18548-gb0daacf58f41.
PR: 271047
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge commit 069ecd0c6e2c from llvm-project (by Fangrui Song):
[ARM] Check target feature support for __builtin_arm_crc*
`__builtin_arm_crc*` requires the target feature crc which is available on armv8
and above. Calling the fuctions for armv7 leads to a SelectionDAG crash.
```
% clang -c --target=armv7-unknown-linux-gnueabi -c a.c
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.crc32b
PLEASE submit a bug report to ...
```
Add `TARGET_BUILTIN` and define required features for these builtins to
report an error in `CodeGenFunction::checkTargetFeatures`. The problem is quite widespread.
I will add `TARGET_BUILTIN` for more builtins later.
Fix https://github.com/llvm/llvm-project/issues/57802
Differential Revision: https://reviews.llvm.org/D134127
Merge commit b2d7a0dcf1ff from llvm-project (by Fangrui Song):
[AArch64] Check target feature support for __builtin_arm_crc*
This is the AArch64 counterpart of D134127.
Daniel Kiss will change more `BUILTIN` to `TARGET_BUILTIN`.
Fix #57802
Note that programs attempting to use ARM/AArch64 CRC intrinsics, when
they are not supported by the targeted CPU, will still receive a regular
compilation error (instead of a fatal backend error) similar to:
7zCrc.c:4:10: error: '__builtin_arm_crc32b' needs target feature crc
return __builtin_arm_crc32b(a, b);
^
Reported by: Alastair Hogge <agh@riseup.net>
PR: 271624
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.2-10-gf3c5289e7846.
PR: 265425
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-9-g1c73596d3454.
PR: 265425
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17485-ga3e38b4a206b.
PR: 265425
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-16436-g18a6ab5b8d1f.
PR: 265425
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
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 commit f1b0a4fc540f from llvm git (by Richard Smith):
An expression should only contain an unexpanded parameter pack if it
lexically contains a mention of the pack.
Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.
Fixes #54402.
MFC after: 3 days
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.4-0-g29f1039a7285, aka 14.0.4 release.
PR: 261742
MFC after: 3 days
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.3-0-g1f9140064dfb.
PR: 261742
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc4-2-gadd3ab7f4c8a.
PR: 261742
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc2-12-g09546e1b5103.
PR: 261742
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc1-74-g4dc3cb8e3255.
PR: 261742
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18294-gdb01b123d012, the last commit before
the upstream release/14.x branch was created.
PR: 261742
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
| |
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.
PR: 261742
MFC after: 2 weeks
|