| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
|
| |
|
|
|
|
| |
This fixes PR14339.
llvm-svn: 169705
|
| |
|
|
|
|
| |
don't mark the function as invalid, since we suppress the error.
llvm-svn: 169689
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
|
| |
|
|
|
|
| |
flavour of special member.
llvm-svn: 169670
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
|
| |
|
|
|
|
| |
defaulted.
llvm-svn: 169574
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
|
| |
an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.
llvm-svn: 169075
|
| |
|
|
|
|
|
|
|
|
|
| |
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
llvm-svn: 168847
|
| |
|
|
|
|
|
| |
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a special member" diagnostic from warning to error, and fix the cases where it
produced diagnostics with incorrect wording.
We don't support this as an extension, and we ban it even in C++98 mode. This
breaks too much (for instance, the ABI-specified calling convention for a type
can change if it acquires a copy constructor through the addition of a default
argument).
llvm-svn: 168769
|
| |
|
|
|
|
| |
add some assertions. No functionality change.
llvm-svn: 168725
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
|
| |
|
|
|
|
| |
Fixes PR14073!
llvm-svn: 168031
|
| |
|
|
|
|
|
| |
test was whether the /selected/ operator= was trivial, not whether the class
had any trivial (or any non-trivial) operator=s.
llvm-svn: 167897
|
| |
|
|
|
|
|
| |
- In C++11, perform overload resolution over all assignment operators, rather than just looking for copy/move assignment operators.
- Clean up after temporaries produced by operator= immediately, rather than accumulating them until the end of the function.
llvm-svn: 167798
|
| |
|
|
|
|
|
|
| |
assignment generation. This incidentally avoids reusing the same Expr* across
multiple statements in the same object; that was generating slightly broken
ASTs, but I couldn't trigger any observable bad behavior, so no test.
llvm-svn: 167779
|
| |
|
|
|
|
|
| |
CXXRecordDecl::forallBases, which does *not* do what I need. Fixes the
failure introduced in r167651.
llvm-svn: 167668
|
| |
|
|
|
|
|
| |
would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>
llvm-svn: 167651
|
| |
|
|
|
|
|
|
| |
to have UsingDirectiveDecl inside anything other than those two.
No user-visible functionality change.
llvm-svn: 167376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
|
| |
|
|
| |
llvm-svn: 166254
|
| |
|
|
|
|
|
|
|
|
|
| |
source locations in places where it is necessary for diagnostics. By itself,
this causes assertions, so while I'm here, also fix property synthesis
for properties of C++ class type so we use so we properly set up a scope
and mark variable declarations.
<rdar://problem/12514189>.
llvm-svn: 166219
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration of a virtual function.
GCC and Clang both do not warn on:
struct a { virtual void func(); };
struct b: a { virtual void func(); void func(int); };
struct c: b { void func(int); using b::func; };
but if the "using" was using a::func GCC would still remain silent where Clang
would warn. This change makes Clang consistent with GCC's existing behavior.
llvm-svn: 166154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
| |
|
|
|
|
|
|
| |
constructor with invalid code.
rdar://12240916
llvm-svn: 165623
|
| |
|
|
|
|
| |
what's going on, per Sean Silva's suggestion.
llvm-svn: 165286
|
| |
|
|
|
|
|
|
| |
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
|
| |
|
|
|
|
|
|
| |
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
|
| |
|
|
|
|
| |
Patch by Andy Gibbs!
llvm-svn: 164590
|
| |
|
|
|
|
| |
instantiations if we encountered errors parsing some of the initializers.
llvm-svn: 164578
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
|
| |
|
|
| |
llvm-svn: 164360
|
| |
|
|
| |
llvm-svn: 164359
|
| |
|
|
|
|
| |
non-function friend declaration. Patch by Josh Magee!
llvm-svn: 164273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes Clang warn about self references in in-class initializers,
for example:
struct S {
int a = a + 42;
};
This basically just moves UninitializedFieldVisitor up a bit in
SemaDeclCXX.cpp, and adds a call to it from ActOnCXXInClassMemberInitializer.
llvm-svn: 164131
|
| |
|
|
| |
llvm-svn: 164033
|
| |
|
|
|
|
| |
delegating initializer, not to the first initializer. For good measure, also highlight the other initializer.
llvm-svn: 163919
|
| |
|
|
|
|
|
|
|
| |
type checking for non-static data member initializers in a dependent
class, because our ASTs lose too much information to when
type-checking an initializer. Fixes <rdar://problem/11974632>,
although the result is still rather unsatisfactory.
llvm-svn: 163871
|
| |
|
|
| |
llvm-svn: 163546
|
| |
|
|
|
|
| |
crash in a corner case. Patch by Olivier Goffart!
llvm-svn: 163337
|
| |
|
|
| |
llvm-svn: 163039
|
| |
|
|
| |
llvm-svn: 163032
|
| |
|
|
|
|
| |
instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins.
llvm-svn: 163013
|
| |
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 162552
|
| |
|
|
|
|
|
|
| |
MutableArrayRef.
This required changing all get() calls to data() and using the simpler constructors.
llvm-svn: 162501
|
| |
|
|
|
|
| |
SmallVector.
llvm-svn: 162492
|
| |
|
|
|
|
|
| |
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
llvm-svn: 162475
|