I accidentally broke friend destructor declarations in D130936.
Modify it to skip performing the destructor name check if we have a dependent friend declaration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D131541
I introduced a patch to handle unqualified templated base class
initialization in MSVC compatibility mode:
https://reviews.llvm.org/rGc894e85fc64dd8d83b460de81080fff93c5ca334
We identified a problem with this patch in the case where the base class
is partially specialized, which can lead to triggering an assertion in
the case of a mix between types and values.
The minimal test case is:
template <typename Type, int TSize> class Vec {};
template <int TDim> class Index : public Vec<int, TDim> {
Index() : Vec() {}
};
template class Index<0>;
The detailed problem is that I was using the
`InjectedClassNameSpecialization`, to which the class template arguments
were then applied in order. But in the process, we were losing all the
partial specializations of the base class and creating an index mismatch
between the expected and passed arguments.
Patch By: frederic-tingaud-sonarsource
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D130709
When expanding undeclared function parameters, we should initialize
the original number of expansions, if known, before trying to expand
them, otherwise a length mismatch with an outer pack might not be
diagnosed.
Fixes PR56094.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131802
DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395.
Reviewed By: aaron.ballman, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128745
DiagnoseNullConversion is needlessly calling isNullPointerConstant which
is an expensive routine due to its calls to a constant evaluator --
which we don't need.
Building the Linux Kernel (x86_64) with this fix has improved build
times by ~2.1%. This is mainly due to the following methods no longer
needing to be called anywhere near as often:
1) ExprConstant::CheckICE (reduced CPU cycles by ~90%)
2) IntExprEvaluator::VisitBinaryOperator (reduced CPU cycles by ~50%)
Reviewed By: rtrieu, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D131532
This patch fixes:
clang/lib/Sema/SemaType.cpp:9469:3: error: default label in switch
which covers all enumeration values
[-Werror,-Wcovered-switch-default]
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
Found during clang 15 RC1 testing due to the new diagnostic added by @royjacobson since clang 14. Uncertain if this fix meets the bar to also be applied to the release branch.
If accepted, I'll need someone with commit access to submit on my behalf.
Reviewed By: royjacobson, aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D131730
Before this patch type traits are checked in Parser, so use type traits
directly did not cause assertion faults. However if type traits are initialized
from a template, we didn't perform arity checks before evaluating. This
patch moves arity checks from Parser to Sema, and performing arity
checks in Sema actions, so type traits get checked corretly.
Crash input:
```
template<class... Ts> bool b = __is_constructible(Ts...);
bool x = b<>;
```
After this patch:
```
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:5:32: error: type trait requires 1 or more arguments; have 0 arguments
template<class... Ts> bool b = __is_constructible(Ts...);
^~~~~~~~~~~~~~~~~~
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:6:10: note: in instantiation of variable template specialization 'b<>' requested here
bool x = b<>;
^
1 error generated.
```
See https://godbolt.org/z/q39W78hsK.
Fixes https://github.com/llvm/llvm-project/issues/57008
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131423
This fixes compilation errors in the following code with
latest libc++ and libstdc++:
```cpp
int main() {
std::tuple<std::string> s;
std::tuple<std::string_view> sv;
s < sv;
}
```
See https://gcc.godbolt.org/z/vGvEhxWvh for the error.
This used to happen because repeated template instantiations during
C++20 constraint satisfaction will cause a call to `RebuildCXXRewrittenBinaryOperator`
with `PerformADL` set to false, see 59351fe340/clang/lib/Sema/TreeTransform.h (L2737)
Committing urgently to unbreak breakages we see in our configurations.
The change seems relatively safe and the right thing to do.
However, I will follow-up with tests and investigation on whether we
need to do this extra semantic checking in the first place next week.
Followup patch for D128083
Previously, using a non-consteval constructor from an consteval constructor would code generates the consteval constructor.
Example
```
template <typename T>
struct S {
T i;
consteval S() = default;
};
struct Foo {
Foo() {}
};
void func() {
S<Foo> three; // incorrectly accepted by clang.
}
```
This happened because clang erroneously disregards `consteval` specifier for a `consteval explicitly defaulted special member functions in a class template` if it has dependent data members without a `consteval default constructor`.
According to
```
C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358):
If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor,
even though a call to such a function cannot appear in a constant
expression.
```
Therefore the `consteval defaulted constructor of a class template` should be considered `consteval` even if the data members' default constructors are not consteval.
Keeping this constructor `consteval` allows complaining while processing the call to data member constructors.
(Same applies for other special member functions).
This works fine even when we have more than one default constructors since we process the constructors after the templates are instantiated.
This does not address initialization issues raised in
[2602](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2602) and compiler divergence seen in https://godbolt.org/z/va9EMvvMe
Fixes: https://github.com/llvm/llvm-project/issues/51593
Differential Revision: https://reviews.llvm.org/D131479
Closing https://github.com/llvm/llvm-project/issues/56826.
The root cause for pr56826 is: when we collect the template args for the
friend, we need to judge if the friend lives in file context. However,
if the friend lives in ExportDecl lexically, the judgement here is
invalid.
The solution is easy. We should judge the non transparent context and
the ExportDecl is transparent context. So the solution should be good.
A main concern may be the patch doesn't handle all the places of the
same defect. I think it might not be bad since the patch itself should
be innocent.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D131651
Previously a diagnostic was given if the expression was not strictly a
DeclRef. Now also allow use of data members inside member functions.
Differential Revision: https://reviews.llvm.org/D131222
This should help address a build failure found after
09117b2189
../tools/clang/lib/Sema/SemaDeclCXX.cpp: In member function void clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*):
../tools/clang/lib/Sema/SemaDeclCXX.cpp:16666:19: error: declaration of const clang::Expr* clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*)::<unnamed struct>::Expr changes meaning of Expr [-fpermissive]
16666 | const Expr *Expr;
| ^~~~
In file included from ../tools/clang/include/clang/AST/DeclCXX.h:22,
from ../tools/clang/include/clang/AST/ASTLambda.h:18,
from ../tools/clang/lib/Sema/SemaDeclCXX.cpp:15:
../tools/clang/include/clang/AST/Expr.h:109:7: note: Expr declared here as class clang::Expr
109 | class Expr : public ValueStmt {
| ^~~~
At the moment, Clang only considers errno when deciding if a builtin
is const. This ignores the fact that some library functions may raise
floating point exceptions, which may modify global state, e.g. when
updating FP status registers.
To model the fact that some library functions/builtins may raise
floating point exceptions, this patch adds a new 'g' modifier for
builtins. If a builtin is marked with 'g', it cannot be considered
const, unless FP exceptions are ignored.
So far I've not added CHECK lines for all calls in math-libcalls.c. I'll
do that once we agree on the overall direction.
A consequence seems to be that we fail to select some of the constrained
math builtins now, but I am not entirely sure what's going on there.
Reviewed By: john.brawn
Differential Revision: https://reviews.llvm.org/D129231
For failed static assertions, try to take the expression apart and print
useful information about why it failed. In particular, look at binary
operators and print the compile-time evaluated value of the LHS/RHS.
Differential Revision: https://reviews.llvm.org/D130894
A one-bit signed bit-field can only hold the values 0 and -1; this
corrects the diagnostic behavior accordingly.
Fixes#53253
Differential Revision: https://reviews.llvm.org/D131255
As was observed in https://reviews.llvm.org/D123627#3707635, it's
confusing that a user can write:
```
float rintf(void) {}
```
and get a warning, but writing:
```
float rintf() {}
```
gives an error. This patch changes the behavior so that both are
warnings, so that users who have functions which conflict with a
builtin identifier can still use that identifier as they wish.
Differential Revision: https://reviews.llvm.org/D131499
Earlier, if the QualType was sugared, then we would error out
as it was not a pointer type, for example,
typedef int *int_star;
int_star __ptr32 p;
Now, if ptr32 is given we apply it if the raw Canonical Type
(i.e., the desugared type) is a PointerType, instead of only
checking whether the sugared type is a pointer type.
As before, we still disallow ptr32 usage if the pointer is used
as a pointer to a member.
Differential Revision: https://reviews.llvm.org/D130123
Consider:
A == 5 && A != 5
IfA is 5, the old collectConjunctionTerms() would call itself again for
the LHS (which it ignores), then the RHS (which it also ignores) and
then just return without ever adding anything to the Terms array.
Differential Revision: https://reviews.llvm.org/D131070
-E option will set entry function for hlsl.
The format is -E entry_name.
To avoid conflict with existing option with name 'E', add an extra prefix '--'.
A new field HLSLEntry is added to TargetOption.
To share code with HLSLShaderAttr, entry function will be add HLSLShaderAttr attribute too.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D124751
This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805
mentiond two compile-time string cases. And this patch partially fixes
one.
```
constexpr const char* foo() {
return "%s %d";
}
int main() {
printf(foo(), "abc", "def");
return 0;
}
```
This patch enables clang check format string for this:
```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
printf(foo(), "abc", "def");
~~~~~ ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
^~
%s
1 warning generated.
```
Reviewed By: aaron.ballman
Signed-off-by: YingChi Long <me@inclyc.cn>
Differential Revision: https://reviews.llvm.org/D130906
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
We already correctly rejected:
typedef __attribute__((vector_size(16))) _BitInt(4) Ty;
but we would assert with:
typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty;
Now we issue the same error in both cases.
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
https://github.com/llvm/llvm-project/issues/56884
The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild
for field expression. No need for member function call.
The fix is to check field for member expression and skip rebuild for member
function call.
Differential Revision: https://reviews.llvm.org/D131024
We didn't check that a destructor's name matches the directly enclosing class if the class was dependent.
I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests.
Fixes GitHub issue #56772
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D130936
1. Add policy functions support and tests for vadd, vmv, vfmv and all load
instructions except segment load. I didn't add all combination of policy
functions in test because it seem not to make sense.
2. Rename HasUnMaskedOverloaded to SupportOverloading.
3. vmv.s.x for ta policy could not have overloaded API.
4. This patch does not support all operations, I will have other follow-up
patches support all.
[RFC] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/137
Reviewed By: kito-cheng, fakepaper56, fakepaper56
Differential Revision: https://reviews.llvm.org/D126742
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
Yuanfang Chen