| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 162430
|
|
|
|
| |
llvm-svn: 162198
|
|
|
|
|
|
|
|
|
| |
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
|
|
|
|
| |
llvm-svn: 161828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
things going on here that were problematic:
- We were missing the actual access check, or rather, it was suppressed
on account of being a redeclaration lookup.
- The access check would naturally happen during delay, which isn't
appropriate in this case.
- We weren't actually emitting dependent diagnostics associated with
class templates, which was unfortunate.
- Access was being propagated incorrectly for friend method declarations
that couldn't be matched at parse-time.
llvm-svn: 161652
|
|
|
|
|
|
|
|
| |
for side-effects. Instead, check for side-effects after performing
initialization. Doing so also removes some strange corner cases and differences
between in-class initialization and constructor initialization.
llvm-svn: 161449
|
|
|
|
|
|
|
| |
we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.
llvm-svn: 161316
|
|
|
|
|
|
| |
been defined.
llvm-svn: 161315
|
|
|
|
|
|
| |
non-type template parameter pack. Patch by Andy Gibbs!
llvm-svn: 161260
|
|
|
|
| |
llvm-svn: 161211
|