This patch takes advantage of a recent NFC change that refactored
`EvaluateBinaryTypeTrait()` to accept `TypeSourceInfo` instead of
`QualType` c7db450e5c1a83ea768765dcdedfd50f3358d418.
Before:
```
test2.cpp:105:55: error: variable length arrays are not supported in '__is_layout_compatible'
105 | static_assert(!__is_layout_compatible(int[n], int[n]));
| ^
test2.cpp:125:76: error: incomplete type 'CStructIncomplete' where a complete type is required
125 | static_assert(__is_layout_compatible(CStructIncomplete, CStructIncomplete));
| ^
```
After:
```
test2.cpp:105:41: error: variable length arrays are not supported in '__is_layout_compatible'
105 | static_assert(!__is_layout_compatible(int[n], int[n]));
| ^
test2.cpp:125:40: error: incomplete type 'CStructIncomplete' where a complete type is required
125 | static_assert(__is_layout_compatible(CStructIncomplete, CStructIncomplete));
| ^
```
This fixes some problems wrt dependence of captures in lambdas with
an explicit object parameter.
[temp.dep.expr] states that
> An id-expression is type-dependent if [...] its terminal name is
> - associated by name lookup with an entity captured by copy
> ([expr.prim.lambda.capture]) in a lambda-expression that has
> an explicit object parameter whose type is dependent [dcl.fct].
There were several issues with our implementation of this:
1. we were treating by-reference captures as dependent rather than
by-value captures;
2. tree transform wasn't checking whether referring to such a
by-value capture should make a DRE dependent;
3. when checking whether a DRE refers to such a by-value capture, we
were only looking at the immediately enclosing lambda, and not
at any parent lambdas;
4. we also forgot to check for implicit by-value captures;
5. lastly, we were attempting to determine whether a lambda has an
explicit object parameter by checking the `LambdaScopeInfo`'s
`ExplicitObjectParameter`, but it seems that that simply wasn't
set (yet) by the time we got to the check.
All of these should be fixed now.
This fixes#70604, #79754, #84163, #84425, #86054, #86398, and #86399.
Original commit message:
"
Commit https://github.com/llvm/llvm-project/commit/46f3ade introduced a notion
of printing the attributes on the left to improve the printing of attributes
attached to variable declarations. The intent was to produce more GCC compatible
code because clang tends to print the attributes on the right hand side which is
not accepted by gcc.
This approach has increased the complexity in tablegen and the attrubutes
themselves as now the are supposed to know where they could appear. That lead to
mishandling of the `override` keyword which is modelled as an attribute in
clang.
This patch takes an inspiration from the existing approach and tries to keep the
position of the attributes as they were written. To do so we use simpler
heuristic which checks if the source locations of the attribute precedes the
declaration. If so, it is considered to be printed before the declaration.
Fixes https://github.com/llvm/llvm-project/issues/87151
"
The reason for the bot breakage is that attributes coming from ApiNotes are not
marked implicit even though they do not have source locations. This caused an
assert to trigger. This patch forces attributes with no source location
information to be printed on the left. That change is consistent to the overall
intent of the change to increase the chances for attributes to compile across
toolchains and at the same time the produced code to be as close as possible to
the one written by the user.
Commit https://github.com/llvm/llvm-project/commit/46f3ade introduced a
notion of printing the attributes on the left to improve the printing of
attributes attached to variable declarations. The intent was to produce
more GCC compatible code because clang tends to print the attributes on
the right hand side which is not accepted by gcc.
This approach has increased the complexity in tablegen and the
attrubutes themselves as now the are supposed to know where they could
appear. That lead to mishandling of the `override` keyword which is
modelled as an attribute in clang.
This patch takes an inspiration from the existing approach and tries to
keep the position of the attributes as they were written. To do so we
use simpler heuristic which checks if the source locations of the
attribute precedes the declaration. If so, it is considered to be
printed before the declaration.
Fixes https://github.com/llvm/llvm-project/issues/87151
This is a follow-up to #81506. As discussed in #87737, we're rejecting
incomplete types, save for exceptions listed in the C++ standard (`void`
and arrays of unknown bound). Note that arrays of unknown bound of
incomplete types are accepted.
Since we're happy with the current behavior of this intrinsic for
flexible array members
(https://github.com/llvm/llvm-project/pull/87737#discussion_r1553652570),
I added a couple of tests for that as well.
This is a follow-up to #81506. Since `__is_layout_compatible()` is a C++
intrinsic
(ff1e72d68d/clang/include/clang/Basic/TokenKinds.def (L523)),
I don't think we should define how it interacts with VLA extension
unless we have a compelling reason to.
Since #81506 was merged after 18 cut-off, we don't have to follow any
kind of deprecation process.
Try to fix https://github.com/llvm/llvm-project/issues/86790
`getFETokenInfo` requires `DeclarationName` shouldn't be empty and this
will produce crash when checking name conflict of an anonymous
`NamedDecl` in `Sema::PushOnScopeChains` and whether it's a reserved
identifier or not. These wouldn't happen when it's a anonymous enum and
we can skip the checking and just add the declaration to current scope.
Co-authored-by: huqizhi <836744285@qq.com>
Emit `-Wunused-but-set-variable` warning on C++ variables whose
declaration (with initializer) entirely consist the condition expression
of a if/while/for construct but are not actually used in the body of the
if/while/for construct.
Fixes#41447
Fixes https://github.com/llvm/llvm-project/issues/85385.
The Finder was missing for this case, for the crash test, the template
parameter TTP was incorrectly considered as not referenced/appeared in
the template arguments of the right hand side of the alias template
decl, thus the synthesized deduction decl doesn't contain this TTP in
the template parameter list, but we have references in the declaration,
thus it caused crashes.
Clang erroneously rejects the following:
```
template<typename T>
struct A
{
template<typename U>
auto f();
};
template<>
template<typename U>
auto A<int>::f(); // error: conflicting types for 'f'
```
This happens because the explicit specialization of `f` has its return
type replaced with a dependent `AutoType` in `ActOnFunctionDeclarator`,
but no such replacement occurs for the implicitly instantiated function
template `A<int>::f`. Since the return types don't match, the explicit
specialization is diagnosed as an invalid redeclaration.
This patch moves the replacement of the return type to
`CheckFunctionDeclaration` so it also happens during instantiation.
`setObjectOfFriendDecl` will have been called by then, so the `isFriend
&& CurContext->isDependentContext()` condition is made redundant &
removed (as it already happens in `DeclContext::isDependentContext`).
`Sema::IsOverload` only checks the _declared_ return type (which isn't
changed by the adjustment), so adjusting the return type afterwards
should be safe.
This reverts commit ca4c4a6758d184f209cb5d88ef42ecc011b11642.
This was intended not to introduce new consistency diagnostics for
smart pointer types, but failed to ignore sugar around types when
detecting this.
Fixed and test added.
Fixes#85406.
- Set the invalid bit for alias template decl where it has multiple
written template parameter lists (as the AST node is ill-formed)
- don't perform CTAD for invalid alias template decls
This attribute tells the compiler that the variable must have its exit-time
destructor run, so it makes sense that it would silence the warning telling
users that an exit-time destructor is required.
Fixes https://github.com/llvm/llvm-project/issues/68686
This was a limitation which has now been lifted. Please read the
thread below for more details:
https://github.com/llvm/llvm-project/pull/84405#discussion_r1525583647
Basically it allows to separate versioned implementations across
different TUs without having to share private header files which
contain the default declaration.
The ACLE spec has been updated accordingly to make this explicit:
"Each version declaration should be visible at the translation
unit in which the corresponding function version resides."
https://github.com/ARM-software/acle/pull/310
If a resolver is required (because there is a caller in the TU),
then a default declaration is implicitly generated.
We want to add -Wcast-function-type to -Wextra (as done in
1de7e6c8cba27296f3fc16d107822ea0ee856759), but we do not want to add
-Wcast-function-type-strict in at the same time
(https://lab.llvm.org/buildbot/#/builders/57/builds/33601/steps/5/logs/stdio).
This moves the existing warning to a new group
(-Wcast-function-type-mismatch), puts the new group under the existing
-Wcast-function-type warning group, and adds
-Wcast-function-type-mismatch to -Wextra.
The -Wcast-fuction-type-strict has been moved under dignstic group
-Wextra.
Edited the test cases for -Wcast-fuction-type-strict and
-Wcast-fuction-type in Sema an SemaCXX.
Added a new test case which include a functionality that was already in
the -Wextra group, i.e -Wignored-qualifiers with
-Wcast-fuction-type-strict.
Fixes: #76872
Predefined macro FUNCTION in clang is not returning the same string than
MS for templated functions.
See https://godbolt.org/z/q3EKn5zq4
For the same test case MSVC is returning:
function: TestClass::TestClass
function: TestStruct::TestStruct
function: TestEnum::TestEnum
The initial work for this was in the reverted patch
(https://github.com/llvm/llvm-project/pull/66120). This patch solves the
issues raised in the reverted patch.
Prior to this commit, clang would fail to produce a constant value for
`b` in:
```c++
struct base {
};
struct s : base {
int z;
};
constexpr auto b = std::bit_cast<s>(0x12);
```
e.g. https://godbolt.org/z/srrbTMPq4
This reverts commit 92a09c0165b87032e1bd05020a78ed845cf35661.
This is triggering a bunch of new -Wnullability-completeness warnings
in code with existing raw pointer nullability annotations.
The intent was the new nullability locations wouldn't affect those
warnings, so this is a bug at least for now.
This enables clang and external nullability checkers to make use of
these annotations on nullable C++ class types like unique_ptr.
These types are recognized by the presence of the _Nullable attribute.
Nullable standard library types implicitly receive this attribute.
Existing static warnings for raw pointers are extended to smart
pointers:
- nullptr used as return value or argument for non-null functions
(`-Wnonnull`)
- assigning or initializing nonnull variables with nullable values
(`-Wnullable-to-nonnull-conversion`)
It doesn't implicitly add these attributes based on the assume_nonnull
pragma, nor warn on missing attributes where the pragma would apply
them.
I'm not confident that the pragma's current behavior will work well for
C++ (where type-based metaprogramming is much more common than C/ObjC).
We'd like to revisit this once we have more implementation experience.
Support can be detected as `__has_feature(nullability_on_classes)`.
This is needed for back-compatibility, as previously clang would issue a
hard error when _Nullable appears on a smart pointer.
UBSan's `-fsanitize=nullability` will not check smart-pointer types.
It can be made to do so by synthesizing calls to `operator bool`, but
that's left for future work.
Discussion:
https://discourse.llvm.org/t/rfc-allowing-nonnull-etc-on-smart-pointers/77201/26
Revert "[Clang][C++23] Implement P2448R2: Relaxing some constexpr
restrictions (#77753)"
This reverts commit 99500e8c08a4d941acb8a7eb00523296fb2acf7a because it
causes a behavior change for std=c++20. See
https://github.com/llvm/llvm-project/pull/77753.
There were some bugs wrt explicit object parameters in lambdas in the
constant evaluator:
- The code evaluating a `CXXThisExpr` wasn’t checking for explicit
object parameters at all and thus assumed that there was no `this` in
the current context because the lambda didn’t have one, even though we
were in a member function and had captured its `this`.
- The code retrieving captures as lvalues *did* account for explicit
object parameters, but it did not handle the case of the explicit object
parameter being passed by value rather than by reference.
This fixes#80997.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
We ignored the require-clause of the original template when building the deduction guide for type-alias CTAD, this resulted in accepting code which should be rejected (see the test case). This patch fixes it, part of #84492.
We previously were not adding them to the candidate set and so use of a
bit-precise integer as a class member could lead to ambiguous overload
sets.
Fixes https://github.com/llvm/llvm-project/issues/82998
Consistent with `__is_trivially_copyable(volatile int) == true` and
`__is_trivially_relocatable(volatile Trivial) == true`,
`__is_trivially_relocatable(volatile int)` should also be `true`.
Fixes https://github.com/llvm/llvm-project/issues/77091
[clang] [test] New tests for __is_trivially_relocatable(cv-qualified
type)
Fix a test that was added in #81014 and which caused buildbots to fail.
Only check for the ‘never produces a constant expression error’ in C++20
mode.
This fixes#84623.
This implements the C++23 `[[assume]]` attribute.
Assumption information is lowered to a call to `@llvm.assume`, unless the expression has side-effects, in which case it is discarded and a warning is issued to tell the user that the assumption doesn’t do anything. A failed assumption at compile time is an error (unless we are in `MSVCCompat` mode, in which case we don’t check assumptions at compile time).
Due to performance regressions in LLVM, assumptions can be disabled with the `-fno-assumptions` flag. With it, assumptions will still be parsed and checked, but no calls to `@llvm.assume` will be emitted and assumptions will not be checked at compile time.
In valid code, there should only be a very specific set of members in a
lambda definition. If the user tries to define something inside the
lambda class, this assumption is violated and causes an assertion error.
This can be fixed by checking whether the members are valid, and if not,
ignore that the class members are potentially unexpected.
I've come across this while working on implementing lambdas in C++03.
Fix#84064
According to http://eel.is/c++draft/dcl.fct.def.coroutine#9 the first
parameter for overload resolution of `operator new` is `size_t` followed
by the arguments of the coroutine function.
http://eel.is/c++draft/dcl.fct.def.coroutine#4 states that the first
argument is the lvalue of `*this` if the coroutine is a member function.
Before this patch, Clang handled class types correctly but ignored
lambdas. This patch adds support for lambda coroutines with a
`promise_type` that implements a custom `operator new`.
The patch does consider C++23 `static operator()`, which already worked
as there is no `this` parameter.
Fixes#54051
This patch implements the C++20 feature -- CTAD for alias templates (P1814R0, specified in https://eel.is/c++draft/over.match.class.deduct#3). It is an initial patch:
- it cover major pieces, thus it works for most cases;
- the big missing piece is to implement the associated constraints (over.match.class.deduct#3.3) for the synthesized deduction guides, see the FIXME in code and tests;
- Some enhancements on the TreeTransform&TemplateInstantiator to allow performing instantiation on `BuildingDeductionGuides` mode;
Per
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2448r2.html
function/constructor/destructor can be marked `constexpr` even though it
never produces a constant expression.
Non-literal types as return types and parameter types of functions
marked `constexpr` are also allowed.
Since this is not a DR, the diagnostic messages are still preserved for
C++ standards older than C++23.
There are code bases that inline `std::move` manually via `static_cast`.
Treat a static cast to an xvalue as an inlined `std::move` call and warn
on a self move.
