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
There is no functional change here (hence no new tests). The only change
is to replace a couple uintptr_t members with llvm::PointerIntPair<> to
clean up the code, making it more readable and less error prone.
This cleanup highlighted that the old code was effectively casting away
const. This is fixed by changing some function signatures.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D98889
There is no need to check for enabled pragma for core or optional core features,
thus this check is removed
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D97058
See https://bugs.llvm.org/show_bug.cgi?id=42154.
GCC's __attribute__((align)) can reduce the alignment of a type when applied to
a typedef. However, functions which take a pointer or reference to the
original type are compiled assuming the original alignment. Therefore when any
such function is passed an object of the new, less-aligned type, an alignment
fault can occur. In particular, this applies to the constructor, which is
defined for the original type and called for the less-aligned object.
This change adds a warning whenever an pointer or reference to an object is
passed to a function that was defined for a more-aligned type.
The calls to ASTContext::getTypeAlignInChars seem change the order in which
record layouts are evaluated, which caused changes to the output of
-fdump-record-layouts. As such some tests needed to be updated:
* Use CHECK-LABEL rather than counting the number of "Dumping AST Record
Layout" headers.
* Check for end of line in labels, so that struct B1 doesn't match struct B
etc.
* Add --strict-whitespace, since the whitespace shows meaningful structure.
* The order in which record layouts are printed has changed in some cases.
* clang-format for regions changed
Differential Revision: https://reviews.llvm.org/D97187
This is a corner of the differences between C99 designators and C++20
designators that we'd previously overlooked. As with other such cases,
this continues to be permitted as an extension and allowed by default,
behind the -Wc99-designators warning flag, except in cases where it
leads to a conformance difference (such as in overload resolution and in
a SFINAE context).
Prevent materializing temporaries in the address space of the references
they are bind to. The temporaries should always be in the same address
space - private for OpenCL.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D95608
reference binding to an expression.
We need to know the array bound in order to determine whether the
parameter type is reference-compatible with the argument type, so we
need to trigger instantiation in this case.
Like the VarDecl that gets its type updated based on an init-list, this
patch corrects the MaterializeTemporaryExpr's type to make sure it isn't
creating an incomplete type, which leads to a handful of CodeGen crashes
(see PR 47636).
Based on @rsmith 's comments on D88236
Differential Revision: https://reviews.llvm.org/D88298
In implicitly movable test, a two-stage overload resolution is performed.
If the first overload resolution selects a deleted function, Clang directly
performs the second overload resolution, without checking whether the
deleted function matches the additional criteria.
This patch fixes the above problem.
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D92936
In implicitly movable test, a two-stage overload resolution is performed.
If the first overload resolution selects a deleted function, Clang directly
performs the second overload resolution, without checking whether the
deleted function matches the additional criteria.
This patch fixes the above problem.
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D92936
Technically 'noexcept' isn't a qualifier, so this should be a separate conversion.
Also make the test a pure frontend test.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D67112
non-type template parameters.
Create a unique TemplateParamObjectDecl instance for each such value,
representing the globally unique template parameter object to which the
template parameter refers.
No IR generation support yet; that will follow in a separate patch.
folding to not constant folding.
Constant folding of ICEs is done as a GCC compatibility measure, but new
code was picking it up, presumably by accident, due to the bad default.
While here, also switch the flag from a bool to an enum to make it more
obvious what it means at call sites. This highlighted a couple of places
where our behavior is different between C++11 and C++14 due to switching
from checking for an ICE to checking for a converted constant
expression (where there is no 'fold' codepath).
The function `TryListConversion` didn't properly validate the following
part of the standard:
Otherwise, if the parameter type is a character array [... ]
and the initializer list has a single element that is an
appropriately-typed string literal (8.5.2 [dcl.init.string]), the
implicit conversion sequence is the identity conversion.
This caused the following call to `f()` to be ambiguous.
void f(int(&&)[1]);
void f(unsigned(&&)[1]);
void g(unsigned i) {
f({i});
}
This issue only occurs when the initializer list had one element.
Differential Revision: https://reviews.llvm.org/D87561
This is recommit of 6c8041aa0f, reverted in de044f7562 because of some
fails. Original commit message is below.
This change allow a CastExpr to have optional FPOptionsOverride object,
stored in trailing storage. Of all cast nodes only ImplicitCastExpr,
CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed
to have FPOptions.
Differential Revision: https://reviews.llvm.org/D85960
This change allow a CastExpr to have optional FPOptionsOverride object,
stored in trailing storage. Of all cast nodes only ImplicitCastExpr,
CStyleCastExpr, CXXFunctionalCastExpr and CXXStaticCastExpr are allowed
to have FPOptions.
Differential Revision: https://reviews.llvm.org/D85960
- Prevent nullptr-deference at try to emit warning for invalid `expr`
- Simplify `InitListChecker::UpdateStructuredListElement()` usages. We do not need to check `expr` and increment `StructuredIndex` (for invalid `expr`) before the call anymore.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D85193
When a semantic checking fails on a syntactic InitListExpr, we will
get an ill-formed semantic InitListExpr (e.g. some inits are nullptr),
using this semantic InitListExpr in clang (without setting the err-bits) is crashy.
Differential Revision: https://reviews.llvm.org/D84140
__builtin_va_*() and __builtin_ms_va_*() are declared as functions with a
parameter of reference type.
This patch fixes a crash when using these functions in C where an argument
of structure type is incompatible with the parameter type.
Differential Revision: https://reviews.llvm.org/D82805
Reviewed By: riccibruno
Patch by: Aleksandr Platonov <platonov.aleksandr@huawei.com>
`noderef` was failing to trigger warnings in some cases related to c++ style
casting. This patch addresses them.
Differential Revision: https://reviews.llvm.org/D77836
Summary:
The Initializer of a InitListExpr can be reset to null, which leads to
nullptr-acces crashes.
Reviewers: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80980
This patch implements matrix index expressions
(matrix[RowIdx][ColumnIdx]).
It does so by introducing a new MatrixSubscriptExpr(Base, RowIdx, ColumnIdx).
MatrixSubscriptExprs are built in 2 steps in ActOnMatrixSubscriptExpr. First,
if the base of a subscript is of matrix type, we create a incomplete
MatrixSubscriptExpr(base, idx, nullptr). Second, if the base is an incomplete
MatrixSubscriptExpr, we create a complete
MatrixSubscriptExpr(base->getBase(), base->getRowIdx(), idx)
Similar to vector elements, it is not possible to take the address of
a MatrixSubscriptExpr.
For CodeGen, a new MatrixElt type is added to LValue, which is very
similar to VectorElt. The only difference is that we may need to cast
the type of the base from an array to a vector type when accessing it.
Reviewers: rjmccall, anemet, Bigcheese, rsmith, martong
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D76791
The built-in SVE types are supposed to be treated as opaque types.
This means that for initialisation purposes they should be treated
as a single unit, much like a scalar type.
However, as Eli pointed out, actually using "scalar" in the diagnostics
is likely to cause confusion, given the types are logically vectors.
The patch therefore uses custom diagnostics or generalises existing
ones. Some of the messages use the word "indivisible" to try to make
it clear(er) that these types can't be initialised elementwise.
I don't think it's possible to trigger warn_braces_around_(scalar_)init
for sizeless types as things stand, since the types can't be used as
members or elements of more complex types. But it seemed better to be
consistent with ext_many_braces_around_(scalar_)init, so the patch
changes it anyway.
Differential Revision: https://reviews.llvm.org/D76689
This fixes a common mistake (the 3 should be @3): NSNumber *n = 3. This extends
an existing check for NSString. Also, this only errs if the initializer isn't a
null pointer constant, so NSNumber *n = 0; continues to work. rdar://47029572
Differential revision: https://reviews.llvm.org/D78066
Summary:
Changes:
- handle immediate invocations for constructors.
- add tests
after this patch i believe the implementation of consteval is nearly standard compliant, but IR-gen still needs to be taught not to emit consteval declarations.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: wchilders
Differential Revision: https://reviews.llvm.org/D74007
The C++ rules briefly allowed this, but the rule changed nearly 10 years
ago and we never updated our implementation to match. However, we've
warned on this by default for a long time, and no other compiler accepts
(even as an extension).
In passing, split it up into three values (no explicit functions /
explicit conversion functions only / any explicit functions) in
preparation for using that in a future change.
list constructor when initializing from {}.
We would previously pick between calling an initializer list constructor
and calling a default constructor unstably in this situation, depending
on whether the inherited default constructor had already been used
elsewhere in the program.
The language wording change forgot to update overload resolution to rank
implicit conversion sequences based on qualification conversions in
reference bindings. The anticipated resolution for that oversight is
implemented here -- we order candidates based on qualification
conversion, not only on top-level cv-qualifiers, including ranking
reference bindings against non-reference bindings if they differ in
non-top-level qualification conversions.
For OpenCL/C++, this allows reference binding between pointers with
differing (nested) address spaces. This makes the behavior of reference
binding consistent with that of implicit pointer conversions, as is the
purpose of this change, but that pre-existing behavior for pointer
conversions is itself probably not correct. In any case, it's now
consistently the same behavior and implemented in only one place.
This reinstates commit de21704ba9,
reverted in commit d8018233d1, with
workarounds for some overload resolution ordering problems introduced by
CWG2352.
explicit functions that are not candidates.
It's not always obvious that the reason a conversion was not possible is
because the function you wanted to call is 'explicit', so explicitly say
if that's the case.
It would be nice to rank the explicit candidates higher in the
diagnostic if an implicit conversion sequence exists for their
arguments, but unfortunately we can't determine that without potentially
triggering non-immediate-context errors that we're not permitted to
produce.
This reverts commit de21704ba9.
Regressed/causes this to error due to ambiguity:
void f(const int * const &);
void f(int *);
int main() {
int * x;
f(x);
}
(in case it's important - the original case where this turned up was a
member function overload in a class template with, essentially:
f(const T1&)
f(T2*)
(where T1 == X const *, T2 == X))
It's not super clear to me if this ^ is expected behavior, in which case
I'm sorry about the revert & happy to look into ways to fix the original
code.
The language wording change forgot to update overload resolution to rank
implicit conversion sequences based on qualification conversions in
reference bindings. The anticipated resolution for that oversight is
implemented here -- we order candidates based on qualification
conversion, not only on top-level cv-qualifiers.
For OpenCL/C++, this allows reference binding between pointers with
differing (nested) address spaces. This makes the behavior of reference
binding consistent with that of implicit pointer conversions, as is the
purpose of this change, but that pre-existing behavior for pointer
conversions is itself probably not correct. In any case, it's now
consistently the same behavior and implemented in only one place.
implementing the resolution of CWG2352.
No functionality change, except that we now convert the referent of a
reference binding to the underlying type of the reference in more cases;
we used to happen to preserve the type sugar from the referent if the
only type change was in the cv-qualifiers.
This exposed a bug in how we generate code for trivial assignment
operators: if the type sugar (particularly the may_alias attribute)
got lost during reference binding, we'd use the "wrong" TBAA information
for the load during the assignment.
References need somewhat special treatment. While copying a gsl::Pointer
will propagate the points-to set, creating an object from a reference
often behaves more like a dereference operation.
Differential Revision: https://reviews.llvm.org/D70755
Hana Dusíková