Commit Graph

29 Commits

Author SHA1 Message Date
Richard Smith 5030928d60 [c++20] Implement semantic restrictions for C++20 designated
initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:

 * We continue to permit the full breadth of C99 designated initializers
   in C++, with the exception that we disallow a partial overwrite of an
   initializer with a non-trivially-destructible type. (Full overwrite
   is OK, because we won't run the first initializer at all.)

 * The C99 extensions are disallowed in SFINAE contexts and during
   overload resolution, where they could change the meaning of valid
   programs.

 * C++20 disallows reordering of initializers. We only check for that for
   the simple cases that the C++20 rules permit (designators of the form
   '.field_name =' and continue to allow reordering in other cases).
   It would be nice to improve this behavior in future.

 * All C99 designated initializer extensions produce a warning by
   default in C++20 mode. People are going to learn the C++ rules based
   on what Clang diagnoses, so it's important we diagnose these properly
   by default.

 * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
   so still diagnose C99 extensions as described above. We continue to
   accept designated C++20-compatible initializers in C++ <= 17 silently
   by default (but naturally still reject under -pedantic-errors).

This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.

This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.

Differential Revision: https://reviews.llvm.org/D59754

llvm-svn: 370544
2019-08-30 22:52:55 +00:00
Akira Hatanaka 2ccb31977c [Sema] Check that the destructor for each element of class type is
accessible from the context where aggregate initialization occurs.

rdar://problem/38168772

Differential Revision: https://reviews.llvm.org/D45898

llvm-svn: 341629
2018-09-07 02:38:01 +00:00
Richard Smith 3e268632cf Use zeroinitializer for (trailing zero portion of) large array initializers
more reliably.

This re-commits r333044 with a fix for PR37560.

llvm-svn: 333141
2018-05-23 23:41:38 +00:00
Hans Wennborg 156349fa10 Revert r333044 "Use zeroinitializer for (trailing zero portion of) large array initializers"
It caused asserts, see PR37560.

> Use zeroinitializer for (trailing zero portion of) large array initializers
> more reliably.
>
> Clang has two different ways it emits array constants (from InitListExprs and
> from APValues), and both had some ability to emit zeroinitializer, but neither
> was able to catch all cases where we could use zeroinitializer reliably. In
> particular, emitting from an APValue would fail to notice if all the explicit
> array elements happened to be zero. In addition, for large arrays where only an
> initial portion has an explicit initializer, we would emit the complete
> initializer (which could be huge) rather than emitting only the non-zero
> portion. With this change, when the element would have a suffix of more than 8
> zero elements, we emit the array constant as a packed struct of its initial
> portion followed by a zeroinitializer constant for the trailing zero portion.
>
> In passing, I found a bug where SemaInit would sometimes walk the entire array
> when checking an initializer that only covers the first few elements; that's
> fixed here to unblock testing of the rest.
>
> Differential Revision: https://reviews.llvm.org/D47166

llvm-svn: 333067
2018-05-23 08:24:01 +00:00
Richard Smith 9062bbf419 Use zeroinitializer for (trailing zero portion of) large array initializers
more reliably.

Clang has two different ways it emits array constants (from InitListExprs and
from APValues), and both had some ability to emit zeroinitializer, but neither
was able to catch all cases where we could use zeroinitializer reliably. In
particular, emitting from an APValue would fail to notice if all the explicit
array elements happened to be zero. In addition, for large arrays where only an
initial portion has an explicit initializer, we would emit the complete
initializer (which could be huge) rather than emitting only the non-zero
portion. With this change, when the element would have a suffix of more than 8
zero elements, we emit the array constant as a packed struct of its initial
portion followed by a zeroinitializer constant for the trailing zero portion.

In passing, I found a bug where SemaInit would sometimes walk the entire array
when checking an initializer that only covers the first few elements; that's
fixed here to unblock testing of the rest.

Differential Revision: https://reviews.llvm.org/D47166

llvm-svn: 333044
2018-05-23 00:09:29 +00:00
Richard Smith 283e2076f6 Suppress -Wmissing-braces warning when aggregate-initializing a struct with a single field that is itself an aggregate.
In C++, such initialization of std::array<T, N> types is guaranteed to work by
the standard, is completely idiomatic, and the "suggested" alternative from
Clang was technically invalid.

llvm-svn: 314838
2017-10-03 20:36:00 +00:00
Richard Smith 505ef81422 Fix defaulted-functions-in-C++98 extension to give the functions the same
effect they would have in C++11. In particular, they do not prevent
value-initialization from performing zero-initialization, nor do they prevent a
struct from being an aggregate.

llvm-svn: 290229
2016-12-21 01:57:02 +00:00
Richard Smith 122f88d481 [c++17] P0135R1: Guaranteed copy elision.
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.

llvm-svn: 288866
2016-12-06 23:52:28 +00:00
Richard Smith bbbe618467 Fix crash in access check for aggregate initialization of base classes. It's
not obvious how to access-check these, so pick a conservative rule until we get
feedback from CWG.

llvm-svn: 262966
2016-03-08 23:17:35 +00:00
Ted Kremenek b79ee57080 Implemented delayed processing of 'unavailable' checking, just like with 'deprecated'.
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.

This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings.  By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent.  It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.

This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated".  It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
 (e.g., "function" instead of "destructor").  By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away.  This diagnostic can likely be further wordsmithed
to be shorter.

llvm-svn: 197627
2013-12-18 23:30:06 +00:00
Sebastian Redl ed2e53222f List-initialization via constructor part 1. Still needs: pretty-printing, overloading, initializer_list.
llvm-svn: 147145
2011-12-22 14:44:04 +00:00
Richard Smith 9ca5c42582 Update all tests other than Driver/std.cpp to use -std=c++11 rather than
-std=c++0x. Patch by Ahmed Charles!

llvm-svn: 141900
2011-10-13 22:29:44 +00:00
Richard Smith a528507418 Implement the suggested resolution of WG21 N3307 issue 19: When determining whether a class is an aggregate in C++0x, treat all functions which are neither deleted nor defaulted as user-provided, not just special member functions. The wording of the standard only defines the term "user-provided" for special member functions, but the intent seems to be that any function can be user-provided.
llvm-svn: 139111
2011-09-05 02:13:09 +00:00
Rafael Espindola 699fc4d15c Revert 135177 to fix PR10363.
Revert "For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either."

This reverts commit ac420c5053d6aa41d59f782caad9e46e5baaf2c2.

llvm-svn: 135210
2011-07-14 22:58:04 +00:00
Sebastian Redl 9c61809c23 For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either.
This is a first baby step towards supporting generalized initializer lists. This also removes an aggregate
test case that was just plain wrong, assuming that non-aggregates couldn't be initialized with initializer lists
in C++11 mode.

llvm-svn: 135177
2011-07-14 19:08:10 +00:00
Alexis Hunt 88c75c311f Clean up trivial default constructors now.
hasTrivialDefaultConstructor() really really means it now.

Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.

The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:

struct foo {
  foo(int);
};

It's kind of bad, but the solution isn't obvious - should

struct foo {
  foo (int) = delete;
};

be an aggregate or not?

Lastly, add a missing initialization to FunctionDecl.

llvm-svn: 131101
2011-05-09 21:45:35 +00:00
Douglas Gregor 8385a06929 Introduce Type::isStructureOrClassType(), which does the obvious
thing. Audit all uses of Type::isStructure(), changing those calls to
isStructureOrClassType() as needed (which is alsmost
everywhere). Fixes the remaining failure in Boost.Utility/Swap.

llvm-svn: 102386
2010-04-26 21:31:17 +00:00
Douglas Gregor 5ab1165531 Improve our handling of user-defined conversions as part of overload
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing simpler
interfaces for checking implicit conversions:

  - It eliminates a case of infinite recursion found in Boost.

  - It eliminates the search for the constructor needed to copy a temporary
    generated by an implicit conversion from overload
    resolution. Overload resolution assumes that, if it gets a value
    of the parameter's class type (or a derived class thereof), there
    is a way to copy if... even if there isn't. We now model this
    properly.

llvm-svn: 101680
2010-04-17 22:01:05 +00:00
John McCall 85f9055955 When pretty-printing tag types, only print the tag if we're in C (and
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).

Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.

llvm-svn: 98149
2010-03-10 11:27:22 +00:00
Anders Carlsson 0bd52403d4 Use new initialization code when dealing with [dcl.init.aggr]p12. This fixes the bug where array elements and member initializers weren't copied correctly.
llvm-svn: 94340
2010-01-24 00:19:41 +00:00
Anders Carlsson 73eb7cd351 Use the new init code for member subobjects.
llvm-svn: 94329
2010-01-23 20:20:40 +00:00
Anders Carlsson 0cf999b663 Switch some array initialization over to the new init code.
llvm-svn: 94327
2010-01-23 20:13:41 +00:00
Anders Carlsson d0849254de Baby steps towards migrating the InitListChecker over to the new initialization code. Pass an InitializedEntity pointer through to most init checker functions. Right now, it's ignored everywhere except when initializing vectors in C++.
llvm-svn: 94325
2010-01-23 19:55:29 +00:00
Douglas Gregor dfdda291e0 Add testcase for PR5817, although the bug was already fixed
llvm-svn: 92858
2010-01-06 22:06:13 +00:00
Eli Friedman 463e523ad8 Switch file-scope assignment initialization over to InitializationSequence.
llvm-svn: 91881
2009-12-22 02:10:53 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Sebastian Redl b426f63302 Sema-check virtual declarations. Complete dynamic_cast checking.
llvm-svn: 58804
2008-11-06 15:59:35 +00:00
Douglas Gregor cfd8ddc6de Keep track of whether a C++ class is an aggregate. Don't allow initialization of non-aggregates with initializer lists.
llvm-svn: 58757
2008-11-05 16:20:31 +00:00