Normally warning is not reported when a field has default initializer.
Do so for anonymous unions with default initializers as well. No release
note since it is a regression in clang 18.
Fixes https://github.com/llvm/llvm-project/issues/70384
If a template is defined via an external AST source, it won't have a
location. When we emit warnings about misusing such templates we
shouldn't emit a "template is declared here" warning with no location,
as that's just confusing.
Reviewers: llvm-beanz, erichkeane, AaronBallman
Reviewed By: erichkeane, AaronBallman
Pull Request: https://github.com/llvm/llvm-project/pull/71264
Adds attribute `[[clang::coro_lifetimebound]]`.
All arguments to a function are considered to be **lifetime bound** if
the function
returns a type annotated with ``[[clang::coro_lifetimebound]]`` and
``[[clang::coro_return_type]]``.
This patch converts `CXXConstructExpr::ConstructionKind` into a scoped enum in namespace scope, making it eligible for forward declaring. This is useful in cases like annotating bit-fields with `preferred_type`.
This patch converts `StringLiteral::StringKind` to a scoped enum in namespace scope. This enabled forward-declarations of this enum where necessary, e.g. for `preferred_type` annotation for bit-fields.
This patch moves `ArraySizeModifier` before `Type` declaration so that it's complete at `ArrayTypeBitfields` declaration. It's also converted to scoped enum along the way.
91088978d712cd7b33610c59f69d87d5a39e3113 shouldn't have removed an
additional check that field has incomplete array type.
Fixes https://github.com/llvm/llvm-project/issues/66300
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Use member's type when printing.
This also fixes a bug in warning diagnostic for out of order
initialization with designated initializers so it points to a valid
source location when an anonymous member is being initialized.
Fixes https://github.com/llvm/llvm-project/issues/63759
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D158526
Prior to this change clang didn't emit missing-field-initializers
warning for designated initializers. The comments say that it is done to
match gcc behavior. However, gcc behaves so only for C. For C++ warnings
are emitted.
Fixes https://github.com/llvm/llvm-project/issues/56628
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D157879
This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).
I also updated standards references and citations to the final wording
in the standard.
This is a C++ feature that allows the use of `_` to
declare multiple variable of that name in the same scope;
these variables can then not be referred to.
In addition, while P2169 does not extend to parameter
declarations, we stop warning on unused parameters of that name,
for consistency.
The feature is backported to all C++ language modes.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D153536
Default member initializations constructed from
a parenthesized aggregate initialization should be constructed
at the location of the left paren, to be consistent with
brace initialization.
Otherwise we get diagmostics and source_location in the wrong places.
Fixes#63903
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D155573
In C++ we are not allowed to use designated initializers to initialize fields
out of order. In some cases when diagnosing this we are crashing because we are
not indexing correctly and therefore going out of bounds.
This fixes: https://github.com/llvm/llvm-project/issues/63605
Differential Revision: https://reviews.llvm.org/D154675
This patch proposes to handle in an uniform fashion
the parsing of strings that are never evaluated,
in asm statement, static assert, attrributes, extern,
etc.
Unevaluated strings are UTF-8 internally and so currently
behave as narrow strings, but these things will diverge with
D93031.
The big question both for this patch and the P2361 paper
is whether we risk breaking code by disallowing
encoding prefixes in this context.
I hope this patch may allow to gather some data on that.
Future work:
Improve the rendering of unicode characters, line break
and so forth in static-assert messages
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D105759
Missing a `withConst`, so when deducing from a string literal, a `const` is erroneously added to the deduced type.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D154301
We did not return an error when failing to producing
a valid expression when performing the initialization of
an aggregate initialized with a parenthesized list of expressions.
This is a regression introduced in Clang 17.
Fixes#63278
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D154486
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
The previous code incorrectly assumed that we would never call
warnBracedScalarInit(...) with a EK_ParenAggInitMember. This patch fixes
the bug by warning when a scalar member is initialized via a braced-init
list when performing a parentehsized aggregate initialization. This
behavior is consistent with parentehsized list aggregate initialization.
Fixes#63008
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D151763
Currently when using designated initializers in C++ we have a few
extension. Two extension which are dangerous involved assigning to
multiple members of union which will likely be a mistake since unions
can only have one active member. I have updated to be a warning by
default.
The second case if when we assign to multiple union members and one of
the previous members had a non-trivial destructor, which could lead to
leaking resources. This one is now an error by default.
Fixes: https://github.com/llvm/llvm-project/issues/62156
Differential Revision: https://reviews.llvm.org/D149694
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.
Differential Revision: https://reviews.llvm.org/D149796
This reverts commit 22e2db6010b029ebd4c6d3d1fd30224d8b3109ef.
Broke buildbots on Windows. It seems standard headers on Windows contain
flexible array members in unions
It was rejected in C, and in a strange way accepted in C++. However, the
support was never properly tested and fully implemented, so just reject
it in C++ mode as well.
This change also fixes crash on attempt to initialize union with flexible
array member. Due to missing check on union, there was a null expression
added to init list that caused crash later.
Fixes https://github.com/llvm/llvm-project/issues/61746
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D147626
Before this patch, initialized class members would have the LifetimeKind
LK_MemInitializer, which does not allow for binding a temporary to a
reference. Binding to a temporary however is allowed in parenthesized
aggregate initialization, even if it leads to a dangling reference. To
fix this, we create a new EntityKind, EK_ParenAggInitMember, which has
LifetimeKind LK_FullExpression.
This patch does *not* attempt to diagnose dangling references as a
result of using this feature.
This patch also refactors TryOrBuildParenListInitialization(...) to
accomodate creating different InitializedEntity objects.
Fixes#61567
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D148274
Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].
Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.
Fixes 62266
[0]: be5f35e24f/clang/lib/Sema/SemaInit.cpp (L685)
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D149389
When calling InitializeBase(...), TryOrBuidlParenListInit(...) needs to
pass in the parent entity; otherwise, we erroneously try to cast
CurContext to a CXXConstructorDecl[0], which can't be done since we're
performing aggregate initialization, not constructor initialization.
Field initialization is not affected, but this patch still adds some
tests for it.
Fixes 62296
[0]: 33d6bd1c66/clang/lib/Sema/SemaAccess.cpp (L1696)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149301
Don't pass in the resolved declaration, because that might be an
inheriting constructor declaration, which should never be used directly
and for which constraint satisfaction checking doesn't work.
Fixes#62361.
The "getField" method is a bit confusing considering we also have a
"getFieldName" method. Instead, use "getFieldDecl" rather than
"getField".
Differential Revision: https://reviews.llvm.org/D147743
A "null" designator won't have a valid location. Try to approximate this
location as best we can in that situation.
Closes 61118
Closes 46132
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D147673
initializer list.
This previously led to some weird behaviors where we would unwrap the
initializer list expression and then try to use the DesignatedInitExprs
as constructor arguments.
Under the C++20 language rules, it's not valid to initialize a
reference-to-aggregate from a designated initializer list, but we have
historically accepted that, as do other compilers, and we continue to
accept that with this change. I've asked WG21 whether this should be
considered a wording defect.
This makes the two interfaces for designators more similar so that it's
easier to merge them together in a future refactoring.
Differential Revision: https://reviews.llvm.org/D147580
This implements support for allowing {} to consistently zero initialize
objects. We already supported most of this work as a GNU extension, but
the C2x feature goes beyond what the GNU extension allowed.
The changes in this patch are:
* Removed the -Wgnu-empty-initializer warning group. The extension is
now a C2x extension warning instead. Note that use of
`-Wno-gnu-empty-initializer seems` to be quite low in the wild
(https://sourcegraph.com/search?q=context%3Aglobal+-file%3A.*test.*+%22-Wno-gnu-empty-initializer%22&patternType=standard&sm=1&groupBy=repo
which currently only gives 8 hits total), so this is not expected to
be an overly disruptive change. But I'm adding the clang vendors
review group just in case this expectation is wrong.
* Reworded the diagnostic wording to be about a C2x extension, added a
pre-C2x compat warning.
* Allow {} to zero initialize a VLA
This functionality is exposed as an extension in all older C modes
(same as the GNU extension was), but does *not* allow the extension for
VLA initialization in C++ due to concern about handling non-trivially
constructible types.
Differential Revision: https://reviews.llvm.org/D147349
* Fix an issue where temporaries initialized via parenthesized aggregate
initialization don't get destroyed.
* Fix an issue where aggregate initialization omits calls to class
members' move constructors after a TreeTransform. This occurs because
the CXXConstructExpr wrapping the call to the move constructor gets
unboxed during a TreeTransform of the wrapping FunctionalCastExpr (as with a
InitListExpr), but unlike InitListExpr, we dont reperform the
InitializationSequence for the list's expressions to regenerate the
CXXConstructExpr. This patch fixes this bug by treating
CXXParenListInitExpr identically to InitListExpr in this regard.
Fixes#61145
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D146465
