This patch updates test files after D105169.
Autogenerated test codes are changed by `utils/update_cc_test_checks.py,` and non-autogenerated test codes are changed as follows:
(1) I wrote a python script that (partially) updates the tests using regex: {F18594904} The script is not perfect, but I believe it gives hints about which patterns are updated to have `noundef` attached.
(2) The remaining tests are updated manually.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108453
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)
This reverts commit 277623f4d5.
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
It seems that Clang 11 regressed functionality that was working in
Clang 10 regarding calling a few overloaded operators in an immediate
context. Specifically, we were not checking for immediate invocations
of array subscripting and the arrow operators, but we properly handle
the other overloaded operators.
This fixes the two problematic operators and adds some test coverage to
show they're equivalent to calling the operator directly.
This addresses PR50779.
This is the second part of p0388, dealing with overloads of list
initialization to incomplete array types. It extends the handling
added in D103088 to permit incomplete arrays. We have to record that
the conversion involved an incomplete array, and so (re-add) a bit flag
into the standard conversion sequence object. Comparing such
conversion sequences requires knowing (a) the number of array elements
initialized and (b) whether the initialization is of an incomplete array.
This also updates the web page to indicate p0388 is implemented (there
is no feature macro).
Differential Revision: https://reviews.llvm.org/D103908
This implements the new implicit conversion sequence to an incomplete
(unbounded) array type. It is mostly Richard Smith's work, updated to
trunk, testcases added and a few bugs fixed found in such testing.
It is not a complete implementation of p0388.
Differential Revision: https://reviews.llvm.org/D102645
`[[clang::fallthrough]]` has meaning for the CFG, but all other
StmtAttrs we currently have don't. So omit them, as AttributedStatements
with children cause several issues and there's no benefit in including
them.
Fixes PR52103 and PR49454. See PR52103 for details.
Differential Revision: https://reviews.llvm.org/D111568
usage of an abstract class type within itself.
We were missing handling for deduction guides (which would assert),
friend declarations, and variable templates. We were mishandling inline
variables and other variables defined inside the class definition.
These diagnostics should be downgraded to warnings, or perhaps removed
entirely, once we implement P0929R2.
Distinct lambda expressions are always considered non-equivalent, so two
token-for-token identical function declarations whose signatures involve
lambda-expressions declare distinct functions.
declaration.
Names starting with an underscore are reserved at the global scope, so
cannot be used as the name of an extern "C" symbol in any scope because
such usages conflict with a name at global scope.
Also do not warn on `#define _foo` or `#undef _foo`.
Only global scope names starting with _[a-z] are reserved, not the use
of such an identifier in any other context.
(This relands 59337263ab and makes sure comma operator
diagnostics are suppressed in a SFINAE context.)
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
This patch adds the following built-ins:
__builtin_vsx_build_pair
__builtin_mma_build_acc
Reviewed By: #powerpc, nemanjai, lei
Differential Revision: https://reviews.llvm.org/D107647
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
Allow multiversioning declarations to match when the actual formal
linkage matches, not just when the storage class is identical.
Additionally, change the ambiguous 'linkage' mismatch to be more
specific and say 'language linkage'.
This improves diagnostic (& important to me, DWARF) accuracy - otherwise
there could be ambiguities between "std::nullptr_t" and some user-defined
type that's /actually/ "nullptr_t" defined in the global namespace.
Differential Revision: https://reviews.llvm.org/D110044
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
Previous changes like D101202 and D104261 have eliminated the special
status that break and continue once had, since now we're making
decisions purely based on the structure of the CFG without regard for
the underlying source code constructs.
This means we don't gain anything from defering handling for these
blocks. Dropping it moves some diagnostics, though arguably into a
better place. We're working around a "quirk" in the CFG that perhaps
wasn't visible before: while loops have an empty "transition block"
where continue statements and the regular loop exit meet, before
continuing to the loop entry. To get a source location for that, we
slightly extend our handling for empty blocks. The source location for
the transition ends up to be the loop entry then, but formally this
isn't a back edge. We pretend it is anyway. (This is safe: we can always
treat edges as back edges, it just means we allow less and don't modify
the lock set. The other way around it wouldn't be safe.)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106715
Previously in D104261 we warned about dropping locks from back edges,
this is the corresponding change for exclusive/shared joins. If we're
entering the loop with an exclusive change, which is then relaxed to a
shared lock before we loop back, we have already analyzed the loop body
with the stronger exclusive lock and thus might have false positives.
There is a minor non-observable change: we modify the exit lock set of a
function, but since that isn't used further it doesn't change anything.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106713
SelectionDAG will promote illegal types up to a power of 2 before
splitting down to a legal type. This will create an IntegerType
with a bit width that must be <= MAX_INT_BITS. This places an
effective upper limit on any type of 2^23 so that we don't try
create a 2^24 type.
I considered putting a fatal error somewhere in the path from
TargetLowering::getTypeConversion down to IntegerType::get, but
limiting the type in IR seemed better.
This breaks backwards compatibility with IR that is using a really
large type. I suspect such IR is going to be very rare due to the
the compile time costs such a type likely incurs.
Prevents the ICE in PR51829.
Reviewed By: efriedma, aaron.ballman
Differential Revision: https://reviews.llvm.org/D109721
This patch adds Big-Endian checks for the existing MMA test cases.
It also changes the target for these test cases to pwr10.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D109126
Extends handling of list initialization of bounded array parameters.
This adds the missing checks on converting each initializer for both
std::initializer_list and arrays. And extends
CompareImplicitConversionSequence to compares array size, for two
conversions to array type.
As noted in this patch, there's a defect in the std concerning the
partial orderability of conversion sequences. DR2492 has a suggested
direction that will be simple to add once it (hopefully) is accepted.
Differential Revision: https://reviews.llvm.org/D103088
- `this` used in lambda expression parameter declarations needs no capture.
- Set up CXXThisOverride for default template arguments of a lambda.
A similar fix to this is c3d2ebb60f.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D102531
This reverts commit 2fbd254aa4, which broke the libc++ CI. I'm reverting
to get things stable again until we've figured out a way forward.
Differential Revision: https://reviews.llvm.org/D108696
Summary: Now in libcxx and clang, all the coroutine components are
defined in std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.
But move the coroutine component into the std namespace may be an break
change. So I planned to split this change into two patch. One in clang
and other in libcxx.
This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace and emit a warning in this case. So the existing codes
wouldn't be break after update compiler.
Test Plan: check-clang, check-libcxx
Reviewed By: lxfind
Differential Revision: https://reviews.llvm.org/D108696
In LLVM IR, `AlignmentBitfieldElementT` is 5-bit wide
But that means that the maximal alignment exponent is `(1<<5)-2`,
which is `30`, not `29`. And indeed, alignment of `1073741824`
roundtrips IR serialization-deserialization.
While this doesn't seem all that important, this doubles
the maximal supported alignment from 512MiB to 1GiB,
and there's actually one noticeable use-case for that;
On X86, the huge pages can have sizes of 2MiB and 1GiB (!).
So while this doesn't add support for truly huge alignments,
which i think we can easily-ish do if wanted, i think this adds
zero-cost support for a not-trivially-dismissable case.
I don't believe we need any upgrade infrastructure,
and since we don't explicitly record the IR version,
we don't need to bump one either.
As @craig.topper speculates in D108661#2963519,
this might be an artificial limit imposed by the original implementation
of the `getAlignment()` functions.
Differential Revision: https://reviews.llvm.org/D108661
The Linux kernel has a macro called IS_ENABLED(), which evaluates to a
constant 1 or 0 based on Kconfig selections, allowing C code to be
unconditionally enabled or disabled at build time. For example:
int foo(struct *a, int b) {
switch (b) {
case 1:
if (a->flag || !IS_ENABLED(CONFIG_64BIT))
return 1;
__attribute__((fallthrough));
case 2:
return 2;
default:
return 3;
}
}
There is an unreachable warning about the fallthrough annotation in the
first case because !IS_ENABLED(CONFIG_64BIT) can be evaluated to 1,
which looks like
return 1;
__attribute__((fallthrough));
to clang.
This type of warning is pointless for the Linux kernel because it does
this trick all over the place due to the sheer number of configuration
options that it has.
Add -Wunreachable-code-fallthrough, enabled under -Wunreachable-code, so
that projects that want to warn on unreachable code get this warning but
projects that do not care about unreachable code can still use
-Wimplicit-fallthrough without having to make changes to their code
base.
Fixes PR51094.
Reviewed By: aaron.ballman, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D107933
The diagnostic texts for warning on attributes that don't appear on the
initial declaration is generally useful. We'd like to re-use it in
D106030, but first let's combine two that already are very similar so we
may re-use it a third time in that commit.
Also, fix a few places that were using notePreviousDefinition to point
to declarations, to instead use diag::note_previous_declaration.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D107613
Previously we would show an error, but keep the member, and also the
CXXRrecordDecl, valid. This could lead to crashes when attempting to
access the record layout or size.
Differential Revision: https://reviews.llvm.org/D105478
This patch replaces the workaround for simpler implicit moves
implemented in D105518.
The Microsoft STL currently has some issues with P2266.
Where before, with -fms-compatibility, we would disable simpler
implicit moves globally, with this change, we disable it only
when the returned expression is in a context contained by
std namespace and is located within a system header.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: aaron.ballman, mibintc
Differential Revision: https://reviews.llvm.org/D105951
An empty enum is used to implement C++'s new-ish "byte" type (to make
sure it's a separate type for overloading, etc - compared to a typedef)
- without any enumerators. Some clang warnings don't make sense in this
sort of situation, so let's skip them for empty enums.
It's arguable that possibly some situations of enumerations without
enumerators might want the previous-to-this-patch behavior (if the enum
is autogenerated and in some cases comes up empty, then maybe a default
in an empty switch would still be considered problematic - so that when
you add the first enumeration you do get a -Wswitch warning). But I
think that's niche enough & this std::byte case is mainstream enough
that we should prioritize the latter over the former.
If someone's got a middle ground proposal to account for both of those
situations, I'm open to patches/suggestions/etc.
Clang implemented the _ExtInt datatype as a bit-precise integer type,
which was then proposed to WG14. WG14 has accepted the proposal
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf), but Clang
requires some additional work as a result.
In the original Clang implementation, we elected to disallow implicit
conversions involving these types until after WG14 finalized the rules.
This patch implements the rules decided by WG14: no integer promotion
for bit-precise types, conversions prefer the larger of the two types
and in the event of a tie (say _ExtInt(32) and a 32-bit int), the
standard type wins.
There are more changes still needed to conform to N2709, but those will
be handled in follow-up patches.
According to https://godbolt.org/z/q5rME1naY and acle, we found that
there are different SVE conversion behaviours between clang and gcc. It turns
out that llvm does not handle SVE predicates width properly.
This patch 1) checks SVE predicates width rightly with svbool_t type.
2) removes warning on svbool_t VLST <-> VLAT/GNUT conversion.
3) disables VLST <-> VLAT/GNUT conversion between SVE vectors and predicates
due to different width.
Differential Revision: https://reviews.llvm.org/D106333
When disabling simpler implicit moves in MSVC compatibility mode as
a workaround in D105518, we forgot to make the opposite change and
enable regular (P1825) implicit moves in the same mode.
As a result, we were not doing any implicit moves at all. OOPS!
This fixes it and adds test for this.
This is a fix to a temporary workaround, there is ongoing
work to replace this, applying the workaround only to
system headers and the ::stl namespace.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106303
The anonymous and non-anonymous bit-field diagnostics are easily
combined into one diagnostic. However, the diagnostic was missing a
"the" that is present in the almost-identically worded
warn_bitfield_width_exceeds_type_width diagnostic, hence the changes to
test cases.
After taking C++98 implicit moves out in D104500,
we put it back in, but now in a new form which preserves
compatibility with pure C++98 programs, while at the same time
giving almost all the goodies from P1825.
* We use the exact same rules as C++20 with regards to which
id-expressions are move eligible. The previous
incarnation would only benefit from the proper subset which is
copy ellidable. This means we can implicit move, in addition:
* Parameters.
* RValue references.
* Exception variables.
* Variables with higher-than-natural required alignment.
* Objects with different type from the function return type.
* We preserve the two-overload resolution, with one small tweak to the
first one: If we either pick a (possibly converting) constructor which
does not take an rvalue reference, or a user conversion operator which
is not ref-qualified, we abort into the second overload resolution.
This gives C++98 almost all the implicit move patterns which we had created test
cases for, while at the same time preserving the meaning of these
three patterns, which are found in pure C++98 programs:
* Classes with both const and non-const copy constructors, but no move
constructors, continue to have their non-const copy constructor
selected.
* We continue to reject as ambiguous the following pattern:
```
struct A { A(B &); };
struct B { operator A(); };
A foo(B x) { return x; }
```
* We continue to pick the copy constructor in the following pattern:
```
class AutoPtrRef { };
struct AutoPtr {
AutoPtr(AutoPtr &);
AutoPtr();
AutoPtr(AutoPtrRef);
operator AutoPtrRef();
};
AutoPtr test_auto_ptr() {
AutoPtr p;
return p;
}
```
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D105756
Support Narrowing conversions to bool in if constexpr condition
under C++23 language mode.
Only if constexpr is implemented as the behavior of static_assert
is already conforming. Still need to work on explicit(bool) to
complete support.
This change is intended as initial setup. The plan is to add
more semantic checks later. I plan to update the documentation
as more semantic checks are added (instead of documenting the
details up front). Most of the code closely mirrors that for
the Swift calling convention. Three places are marked as
[FIXME: swiftasynccc]; those will be addressed once the
corresponding convention is introduced in LLVM.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D95561
This reverts commit 52aeacfbf5.
There isn't full agreement on a path forward yet, but there is agreement that
this shouldn't land as-is. See discussion on https://reviews.llvm.org/D105338
Also reverts unreviewed "[clang] Improve `-Wnull-dereference` diag to be more in-line with reality"
This reverts commit f4877c78c0.
And all the related changes to tests:
This reverts commit 9a0152799f.
This reverts commit 3f7c9cc274.
This reverts commit 329f8197ef.
This reverts commit aa9f58cc2c.
This reverts commit 2df37d5ddd.
This reverts commit a72a441812.
The Microsoft STL currently has some issues with P2266.
We disable it for now in that mode, but we might come back later with a
more targetted approach.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D105518
Ignore top-level qualifiers in casts, which fixes issues in reinterpret_cast.
This rule comes from [expr.type]/8.2.2 which explains that casting to a
pr-qualified type should actually cast to the unqualified type. In C++
this is only done for types that aren't classes or arrays.
Fixes: PR49221
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D102689
Before this patch, the dependence of CallExpr was only computed in the
constructor, the dependence bits might not reflect truth -- some arguments might
be not set (nullptr) during this time, e.g. CXXDefaultArgExpr will be set via
the setArg method in the later parsing stage, so we need to recompute the
dependence bits.
This extends the effects of [[ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html | P1825 ]] to all C++ standards from C++11 up to C++20.
According to Motion 23 from Cologne 2019, P1825R0 was accepted as a Defect Report, so we retroactively apply this all the way back to C++11.
Note that we also remove implicit moves from C++98 as an extension
altogether, since the expanded first overload resolution from P1825
can cause some meaning changes in C++98.
For example it can change which copy constructor is picked when both const
and non-const ones are available.
This also rips out warn_return_std_move since there are no cases where it would be worthwhile to suggest it.
This also fixes a bug with bailing into the second overload resolution
when encountering a non-rvref qualified conversion operator.
This was unnoticed until now, so two new test cases cover these.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D104500
We allow branches to join where one holds a managed lock but the other
doesn't, but we can't do so for back edges: because there we can't drop
them from the lockset, as we have already analyzed the loop with the
larger lockset. So we can't allow dropping managed locks on back edges.
We move the managed() check from handleRemovalFromIntersection up to
intersectAndWarn, where we additionally check if we're on a back edge if
we're removing from the first lock set (the entry set of the next block)
but not if we're removing from the second lock set (the exit set of the
previous block). Now that the order of arguments matters, I had to swap
them in one invocation, which also causes some minor differences in the
tests.
Reviewed By: delesley
Differential Revision: https://reviews.llvm.org/D104261
Word on the grapevine was that the committee had some discussion that
ended with unanimous agreement on eliminating relational function pointer comparisons.
We wanted to be bold and just ban all of them cold turkey.
But then we chickened out at the last second and are going for
eliminating just the spaceship overload candidate instead, for now.
See D104680 for reference.
This should be fine and "safe", because the only possible semantic change this
would cause is that overload resolution could possibly be ambiguous if
there was another viable candidate equally as good.
But to save face a little we are going to:
* Issue an "error" for three-way comparisons on function pointers.
But all this is doing really is changing one vague error message,
from an "invalid operands to binary expression" into an
"ordered comparison of function pointers", which sounds more like we mean business.
* Otherwise "warn" that comparing function pointers like that is totally
not cool (unless we are told to keep quiet about this).
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D104892
During template instantiation involving templated lambdas, clang
could hit an assertion in `TemplateDeclInstantiator::SubstFunctionType`
since the functions are not associated with any `TypeSourceInfo`:
`assert(OldTInfo && "substituting function without type source info");`
This path is triggered when using templated lambdas like the one added as
a test to this patch. To fix this:
- Create `TypeSourceInfo`s for special members and make sure the template
instantiator can get through all patterns.
- Introduce a `SpecialMemberTypeInfoRebuilder` tree transform to rewrite
such member function arguments. Without this, we get errors like:
`error: only special member functions and comparison operators may be defaulted`
since `getDefaultedFunctionKind` can't properly recognize these functions
as special members as part of `SetDeclDefaulted`.
Fixes PR45828 and PR44848
Differential Revision: https://reviews.llvm.org/D88327
Fixes bug 50263
When "unused-private-field" flag is on if you have a struct with private
members and only defaulted comparison operators clang will warn about
unused private fields.
If you where to write the comparison operators by hand no warning is
produced.
This is a bug since defaulting a comparison operator uses all private
members .
The fix is simple, in CheckExplicitlyDefaultedFunction just clear the
list of unused private fields if the defaulted function is a comparison
function.
Differential revision: https://reviews.llvm.org/D102186
A lambda in a function template may be recursively instantiated. The recursive
lambda will cause a lambda function instantiated multiple times, one inside another.
The inner LocalInstantiationScope should not be marked as MergeWithParentScope
since it already has references to locals properly substituted, otherwise it causes
assertion due to the check for duplicate locals in merged LocalInstantiationScope.
Reviewed by: Richard Smith
Differential Revision: https://reviews.llvm.org/D98068
This change caused build errors related to move-only __block variables,
see discussion on https://reviews.llvm.org/D99696
> This expands NRVO propagation for more cases:
>
> Parse analysis improvement:
> * Lambdas and Blocks with dependent return type can have their variables
> marked as NRVO Candidates.
>
> Variable instantiation improvements:
> * Fixes crash when instantiating NRVO variables in Blocks.
> * Functions, Lambdas, and Blocks which have auto return type have their
> variables' NRVO status propagated. For Blocks with non-auto return type,
> as a limitation, this propagation does not consider the actual return
> type.
>
> This also implements exclusion of VarDecls which are references to
> dependent types.
>
> Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
>
> Reviewed By: Quuxplusone
>
> Differential Revision: https://reviews.llvm.org/D99696
This also reverts the follow-on change which was hard to tease apart
form the one above:
> "[clang] Implement P2266 Simpler implicit move"
>
> This Implements [[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html|P2266 Simpler implicit move]].
>
> Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
>
> Reviewed By: Quuxplusone
>
> Differential Revision: https://reviews.llvm.org/D99005
This reverts commits 1e50c3d785 and
bf20631782.
At least LibreOffice has, for mainly historic reasons that would be hard to
change now, a class Any with an overloaded operator >>= that semantically does
not assign to the LHS but rather extracts into the (by-reference) RHS. Which
thus caused false positive -Wunused-but-set-parameter and
-Wunused-but-set-variable after those have been introduced recently.
This change is more conservative about the assumed semantics of overloaded
operators, excluding compound assignment operators but keeping plain operator =
ones. At least for LibreOffice, that strikes a good balance of not producing
false positives but still finding lots of true ones.
(The change to the BinaryOperator case in MaybeDecrementCount is necessary
because e.g. the template f4 test code in warn-unused-but-set-variables-cpp.cpp
turns the += into a BinaryOperator.)
Differential Revision: https://reviews.llvm.org/D103949
Check applied to unbounded (incomplete) arrays and pointers to spot
cases where the computed address is beyond the largest possible
addressable extent of the array, based on the address space in which the
array is delcared, or which the pointer refers to.
Check helps to avoid cases of nonsense pointer math and array indexing
which could lead to linker failures or runtime exceptions. Of
particular interest when building for embedded systems with small
address spaces.
This is version 2 of this patch -- version 1 had some testing issues
due to a sign error in existing code. That error is corrected and
lit test for this chagne is extended to verify the fix.
Originally reviewed/accepted by: aaron.ballman
Original revision: https://reviews.llvm.org/D86796
Reviewed By: aaron.ballman, ebevhan
Differential Revision: https://reviews.llvm.org/D88174
Check applied to unbounded (incomplete) arrays and pointers to spot
cases where the computed address is beyond the largest possible
addressable extent of the array, based on the address space in which the
array is delcared, or which the pointer refers to.
Check helps to avoid cases of nonsense pointer math and array indexing
which could lead to linker failures or runtime exceptions. Of
particular interest when building for embedded systems with small
address spaces.
This is version 2 of this patch -- version 1 had some testing issues
due to a sign error in existing code. That error is corrected and
lit test for this chagne is extended to verify the fix.
Originally reviewed/accepted by: aaron.ballman
Original revision: https://reviews.llvm.org/D86796
Reviewed By: aaron.ballman, ebevhan
Differential Revision: https://reviews.llvm.org/D88174
Clang checks whether the type given to va_arg will automatically cause
undefined behavior, but this check was issuing false positives for
enumerations in C++. The issue turned out to be because
typesAreCompatible() in C++ checks whether the types are *the same*, so
this uses custom logic if the type compatibility check fails.
This issue was found by a user on code like:
typedef enum {
CURLINFO_NONE,
CURLINFO_EFFECTIVE_URL,
CURLINFO_LASTONE = 60
} CURLINFO;
...
__builtin_va_arg(list, CURLINFO); // false positive warning
Given that C++ defers to C for the rules around va_arg, the behavior
should be the same in both C and C++ and not diagnose because int and
CURLINFO are "compatible enough" types for va_arg.
This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.
There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:
struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator
this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.
Differential Revision: https://reviews.llvm.org/D102241
This adds support for p1099's 'using SCOPED_ENUM::MEMBER;'
functionality, bringing a member of an enumerator into the current
scope. The novel feature here, is that there need not be a class
hierarchical relationship between the current scope and the scope of
the SCOPED_ENUM. That's a new thing, the closest equivalent is a
typedef or alias declaration. But this means that
Sema::CheckUsingDeclQualifier needs adjustment. (a) one can't call it
until one knows the set of decls that are being referenced -- if
exactly one is an enumerator, we're in the new territory. Thus it
needs calling later in some cases. Also (b) there are two ways we hold
the set of such decls. During parsing (or instantiating a dependent
scope) we have a lookup result, and during instantiation we have a set
of shadow decls. Thus two optional arguments, at most one of which
should be non-null.
Differential Revision: https://reviews.llvm.org/D100276
The following was found by a customer and is accepted by the other primary
C++ compilers, but fails to compile in Clang:
namespace sss {
double foo(int, double);
template <class T>
T foo(T); // note: target of using declaration
} // namespace sss
namespace oad {
void foo();
}
namespace oad {
using ::sss::foo;
}
namespace sss {
using oad::foo; // note: using declaration
}
namespace sss {
double foo(int, double) { return 0; }
template <class T>
T foo(T t) { // error: declaration conflicts with target of using
return t;
}
} // namespace sss
I believe the issue is that MergeFunctionDecl() was calling
checkUsingShadowRedecl() but only considering a FunctionDecl as a
possible shadow and not FunctionTemplateDecl. The changes in this patch
largely mirror how variable declarations were being handled by also
catching FunctionTemplateDecl.
This attribute applies to a using declaration, and permits importing a
declaration without knowing if that declaration exists. This is useful
for libc++ C wrapper headers that re-export declarations in std::, in
cases where the base C library doesn't provide all declarations.
This attribute was proposed in http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html.
rdar://69313357
Differential Revision: https://reviews.llvm.org/D90188
This addresses pr50497. The argument of a typeid expression is
unevaluated, *except* when it's a polymorphic type. We handle this by
parsing as unevaluated and then transforming to evaluated if we
discover it should have been an evaluated context.
We do the same in TreeTransform<Derived>::TransformCXXTypeidExpr,
entering unevaluated context before transforming and rebuilding the
typeid. But that's incorrect and can lead us to converting to
evaluated context twice -- and hitting an assert.
During normal template instantiation we're always cloning the
expression, but during generic lambda processing we do not necessarily
AlwaysRebuild, and end up with TransformDeclRefExpr unconditionally
calling MarkDeclRefReferenced around line 10226. That triggers the
assert.
// Mark it referenced in the new context regardless.
// FIXME: this is a bit instantiation-specific.
SemaRef.MarkDeclRefReferenced(E);
This patch makes 2 changes.
a) TreeTransform<Derived>::TransformCXXTypeidExpr only enters
unevaluated context if the typeid's operand is not a polymorphic
glvalue. If it is, it keeps the same evaluation context.
b) Sema::BuildCXXTypeId is altered to only transform to evaluated, if
the current context is unevaluated.
Differential Revision: https://reviews.llvm.org/D103258
This is a re-application of dc67299 which was reverted in f63adf5b because
it broke the build. The issue should now be fixed.
Attribution note: The original author of this patch is Erik Pilkington.
I'm only trying to land it after rebasing.
Differential Revision: https://reviews.llvm.org/D91630
At the moment, the matrix support in CheckCXXCStyleCast (added in
D101696) breaks function-style constructor calls that take a
single matrix value, because it is treated as matrix cast.
Instead, unify the C++ matrix cast handling by moving the logic to
TryStaticCast and only handle the case where both types are matrix
types. Otherwise, fall back to the generic mis-match detection.
Suggested by @rjmccall
Reviewed By: SaurabhJha
Differential Revision: https://reviews.llvm.org/D103163
Similar to how we allow managed and asserted locks to be held and not
held in joining branches, we also allow them to be held shared and
exclusive. The scoped lock should restore the original state at the end
of the scope in any event, and asserted locks need not be released.
We should probably only allow asserted locks to be subsumed by managed,
not by (directly) acquired locks, but that's for another change.
Reviewed By: delesley
Differential Revision: https://reviews.llvm.org/D102026
We might encounter an undeduced type before calling getTypeAlignInChars.
NOTE: this retrieves the fix from
8f80c66bd2, which was removed in Adam's
followup fix fbfcfdbf68. We originally
thought the crash was caused by recovery-ast, but it turns out it can
occur for other cases, e.g. typo-correction.
Differential Revision: https://reviews.llvm.org/D102750
Non-comprehensive list of cases:
* Dumping template arguments;
* Corresponding parameter contains a deduced type;
* Template arguments are for a DeclRefExpr that hadMultipleCandidates()
Type information is added in the form of prefixes (u8, u, U, L),
suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template
argument, if MSVC codeview mode is disabled.
Differential revision: https://reviews.llvm.org/D77598
We weren't modifying the lock set when intersecting with one coming
from a break-terminated block. This is inconsistent, since break isn't a
back edge, and it leads to false negatives with scoped locks. We usually
don't warn for those when joining locksets aren't the same, we just
silently remove locks that are not in the intersection. But not warning
and not removing them isn't right.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D101202
There already was a check for undeduced and incomplete types, but it
failed to trigger when outer type (SubstTemplateTypeParm in test) looked
fine, but inner type was not.
Differential Revision: https://reviews.llvm.org/D100667
These are intended to mimic warnings available in gcc.
-Wunused-but-set-variable is triggered in the case of a variable which
appears on the LHS of an assignment but not otherwise used.
For instance:
void f() {
int x;
x = 0;
}
-Wunused-but-set-parameter works similarly, but for function parameters
instead of variables.
In C++, they are triggered only for scalar types; otherwise, they are
triggered for all types. This is gcc's behavior.
-Wunused-but-set-parameter is controlled by -Wextra, while
-Wunused-but-set-variable is controlled by -Wunused. This is slightly
different from gcc's behavior, but seems most consistent with clang's
behavior for -Wunused-parameter and -Wunused-variable.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D100581
There was a missing isInvalid() check leading to an attempt to
instantiate template with an empty instantiation stack.
Differential Revision: https://reviews.llvm.org/D100675
The comment here was introduced in
a3e01cf822 and suggests that we should
handle declaration statements and non-declaration statements the same,
but don't because ProhibitAttributes() can't handle GNU attributes. That
has recently changed, so remove the comment and handle all statements
the same.
Differential Revision: https://reviews.llvm.org/D99936
This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.
The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.
Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.
Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D99517
ICC permits this, and after some extensive testing it looks like we can
support this with very little trouble. We intentionally don't choose to
do this with attribute-target (despite it likely working as well!)
because GCC does not support that, and introducing said
incompatibility doesn't seem worth it.
I recently ran into issues with aggregates and inheritance, I'm using
it for creating a type-safe library where most of the types are build
over "tagged" std::array. After bit of cleaning and enabling -Wall
-Wextra -pedantic I noticed clang only in my pipeline gives me warning.
After a bit of focusing on it I found it's not helpful, and contemplate
disabling the warning all together. After a discussion with other
library authors I found it's bothering more people and decided to fix
it.
Removes this warning:
template<typename T, int N> struct StdArray {
T contents[N];
};
template<typename T, int N> struct AggregateAndEmpty : StdArray<T,N> { };
AggregateAndEmpty<int, 3> p = {1, 2, 3}; // <-- warning here about omitted braces
The previous implementation was insufficient for checking statement
attribute mutual exclusion because attributed statements do not collect
their attributes one-at-a-time in the same way that declarations do. So
the design that was attempting to check for mutual exclusion as each
attribute was processed would not ever catch a mutual exclusion in a
statement. This was missed due to insufficient test coverage, which has
now been added for the [[likely]] and [[unlikely]] attributes.
The new approach is to check all of attributes that are to be applied
to the attributed statement in a group. This required generating
another DiagnoseMutualExclusions() function into AttrParsedAttrImpl.inc.
These proposals make the same changes to both C++ and C and remove a
restriction on standard attributes appearing multiple times in the same
attribute list.
We could warn on the duplicate attributes, but do not. This is for
consistency as we do not warn on attributes duplicated within the
attribute specifier sequence. If we want to warn on duplicated
standard attributes, we should do so both for both situations:
[[foo, foo]] and [[foo]][[foo]].
This implements C-style type conversions for matrix types, as specified
in clang/docs/MatrixTypes.rst.
Fixes PR47141.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D99037
This reworks a small set of tests, as preparatory work for implementing
P2266.
* Run for more standard versions, including c++2b.
* Normalize file names and run commands.
* Adds some extra tests.
New Coroutine tests taken from Aaron Puchert's D68845.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D99225
We already did so for scoped locks acquired in the constructor, this
change extends the treatment to deferred locks and scoped unlocking, so
locks acquired outside of the constructor. Obviously this makes things
more consistent.
Originally I thought this was a bad idea, because obviously it
introduces false negatives when it comes to double locking, but these
are typically easily found in tests, and the primary goal of the Thread
safety analysis is not to find double locks but race conditions.
Since the scoped lock will release the mutex anyway when the scope ends,
the inconsistent state is just temporary and probably fine.
Reviewed By: delesley
Differential Revision: https://reviews.llvm.org/D98747
Set the source ranges for parsed GNU-style attributes in
ParseGNUAttributes(), the same way that ParseCXX11Attributes() does it.
Differential Revision: https://reviews.llvm.org/D75844
Currently, when one or more attributes are mutually exclusive, the
developer adding the attribute has to manually emit diagnostics. In
practice, this is highly error prone, especially for declaration
attributes, because such checking is not trivial. Redeclarations
require you to write a "merge" function to diagnose mutually exclusive
attributes and most attributes get this wrong.
This patch introduces a table-generated way to specify that a group of
two or more attributes are mutually exclusive:
def : MutualExclusions<[Attr1, Attr2, Attr3]>;
This works for both statement and declaration attributes (but not type
attributes) and the checking is done either from the common attribute
diagnostic checking code or from within mergeDeclAttribute() when
merging redeclarations.
As of MSVC 19.28 (2019 Update 8), integral conversion is no longer preferred over floating-to-integral, and so MSVC is more standard conformant and will generate a compiler error on ambiguous call.
Cf. https://godbolt.org/z/E8xsdqKsb.
Initially found during the review of D99641.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D99663
Set the source ranges for parsed GNU-style attributes in
ParseGNUAttributes(), the same way that ParseCXX11Attributes() does it.
Differential Revision: https://reviews.llvm.org/D75844
This fixes https://bugs.llvm.org/show_bug.cgi?id=49534, where the call to the constructor
of the anonymous union is checked and triggers assertion failure when trying to retrieve
the alignment of the `this` argument (which is a union with virtual function).
The extra check for alignment was introduced in D97187.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D98548
Create fix-it hints to fix the order of constructors.
To make this a lot simpler, I've grouped all the warnings for each out of order initializer into 1.
This is necessary as fixing one initializer would often interfere with other initializers.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98745
The original implementation didn't fire on non-template classes when a
base class was an instantiation of a template with a dependent base.
In that case the base of the base is dependent as seen from the base,
but not from the class we're interested in, which isn't a template.
Also it simplifies the code a lot.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98724
Clang currently automates a fair amount of diagnostic checking for
declaration attributes based on the declarations in Attr.td. It checks
for things like subject appertainment, number of arguments, language
options, etc. This patch uses the same machinery to perform diagnostic
checking on statement attributes.
The condition variable is in scope in the loop increment, so we need to
emit the jump destination from wthin the scope of the condition
variable.
For GCC compatibility (and compatibility with real-world 'FOR_EACH'
macros), 'continue' is permitted in a statement expression within the
condition of a for loop, though, so there are two cases here:
* If the for loop has no condition variable, we can emit the jump
destination before emitting the condition.
* If the for loop has a condition variable, we must defer emitting the
jump destination until after emitting the variable. We diagnose a
'continue' appearing in the initializer of the condition variable,
because it would jump past the initializer into the scope of that
variable.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D98816
As a follow-up to D95691, add new diagnostic groups named
pre-c++N-compat to replace the old diagnostic groups with the standards
listed out explicitly. The old group names are retained for backwards
compatibility.
Updates __is_unsigned to have the same behavior as the standard
specifies. This is in line with 511dbd8, which applied the same change
to __is_signed.
Refs D67897.
Differential Revision: https://reviews.llvm.org/D98104
The only time we would consider allowing this is inside a call to
std::allocator<T>::deallocate, whose contract does not permit deletion
of null pointers.
We used to trigger assertion when transforming c-tor with unparsed
default argument. Now we ignore such constructors for this purpose.
Differential Revision: https://reviews.llvm.org/D97965
This patch implements the conditional select operator for
ext_vector_types in C++. It does so by using the same semantics as for
C.
D71463 added support for the conditional select operator for VectorType
in C++. Unfortunately the semantics between ext_vector_type in C are
different to VectorType in C++. Select for ext_vector_type is based on
the MSB of the condition vector, whereas for VectorType it is `!= 0`.
This unfortunately means that the behavior is inconsistent between
ExtVectorType and VectorType, but I think using the C semantics for
ExtVectorType in C++ as well should be less surprising for users.
Reviewed By: erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D98055
Fix duplicate diagnostic for an over-aligned allocation with no matching
function, and add custom diagnostic for the case where the
non-allocating placement new was intended but <new> was not included.
Our diagnostics relating to static assertions were a bit confused. For
instance, when in MS compatibility mode in C (where we accept
static_assert even without including <assert.h>), we would fail
to warn the user that they were using the wrong spelling (even in
pedantic mode), we were missing a compatibility warning about using
_Static_assert in earlier standards modes, diagnostics for the optional
message were not reflected in C as they were in C++, etc.
Previously, -fshow-overloads=best always showed 4 candidates. The
problem is, when this isn't enough, you're kind of up a creek; the only
option available is to recompile with different flags. This can be
quite expensive!
With this change, we try to strike a compromise. The *first* error with
more than 4 candidates will show up to 32 candidates. All further
errors continue to show only 4 candidates.
The hope is that this way, users will have *some chance* of making
forward progress, without facing unbounded amounts of error spam.
Differential Revision: https://reviews.llvm.org/D95754
It would be beneficial to allow not_tail_called attribute to be applied to
virtual functions. I don't see any drawback of allowing this.
Differential Revision: https://reviews.llvm.org/D96832
This happens in codebases a lot, which use xor where both sides are
macros. Using xor in that case is not the common error-prone 2^6 code
that the warning was introduced for.
Don't diagnose such a use of xor.
Differential Revision: https://reviews.llvm.org/D97445
https://bugs.llvm.org/show_bug.cgi?id=40858
CheckShadow is now called for each binding in the structured binding to make sure it does not shadow any other variable in scope. This does use a custom implementation of getShadowedDeclaration though because a BindingDecl is not a VarDecl
Added a few unit tests for this. In theory though all the other shadow unit tests should be duplicated for the structured binding variables too but whether it is probably not worth it as they use common code. The MyTuple and std interface code has been copied from live-bindings-test.cpp
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D96147
This commit prevents warnings from -Wconversion when a clang vector type
is implicitly converted to a sizeless builtin type -- for example, when
implicitly converting a fixed-predicate to a scalable predicate.
The code below:
1 #include <arm_sve.h>
2
3 #define N __ARM_FEATURE_SVE_BITS
4 #define FIXED_ATTR __attribute__((arm_sve_vector_bits (N)))
5 typedef svbool_t fixed_svbool_t FIXED_ATTR;
6
7 inline fixed_svbool_t foo(fixed_svbool_t p) {
8 return svnot_z(svptrue_b64(), p);
9 }
would previously raise this warning:
warning: implicit conversion turns vector to scalar: \
'fixed_svbool_t' (vector of 8 'unsigned char' values) to 'svbool_t' \
(aka '__SVBool_t') [-Wconversion]
Note that many cases of these implicit conversions were already
permitted because many functions inside arm_sve.h are spawned via
preprocessor macros, and the call to isInSystemMacro would cover us in
this case. This commit fixes the remaining cases.
Differential Revision: https://reviews.llvm.org/D97053
Currently TypePrinter lumps anonymous classes and unnamed classes in one group "anonymous" this is not correct and can be confusing in some contexts.
Differential Revision: https://reviews.llvm.org/D96807
Juneyoung Lee