vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134007 91177308-0d34-0410-b5e6-96231b3b80d8
(or follow up) extern declaration with weak_import as
an actual definition. make clang follows this behavior.
// rdar://9538608
llvm-gcc treats an extern declaration with weak_import
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133450 91177308-0d34-0410-b5e6-96231b3b80d8
storage specifier is different from the storage specifier on the
template. If that storage specifier is the same, then we only warn.
Thanks to John for the prodding.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133236 91177308-0d34-0410-b5e6-96231b3b80d8
specifier on an explicit specialization to a warning, since neither
EDG nor GCC diagnose this code as ill-formed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133232 91177308-0d34-0410-b5e6-96231b3b80d8
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
either imlicitly (for builtins) or explicitly (due to multiple
specification of the same attributes). Fixes <rdar://problem/9612060>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133045 91177308-0d34-0410-b5e6-96231b3b80d8
struct {
typedef int A = 0;
};
According to the C++11 standard, this is not ill-formed, but does not have any ascribed meaning. We can't reasonably accept it, so treat it as ill-formed.
Also switch C++ from an incorrect 'fields can only be initialized in constructors' diagnostic for this case to C's 'illegal initializer (only variables can be initialized)'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132890 91177308-0d34-0410-b5e6-96231b3b80d8
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132868 91177308-0d34-0410-b5e6-96231b3b80d8
- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree. Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132831 91177308-0d34-0410-b5e6-96231b3b80d8
specializing a member of an unspecialized template, and recover from
such errors without crashing. Fixes PR10024 / <rdar://problem/9509761>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132677 91177308-0d34-0410-b5e6-96231b3b80d8
class type (or array thereof), eliminating some redundant checks
(thanks Eli!) and adding some tests where the behavior differs in
C++98/03 vs. C++0x.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132218 91177308-0d34-0410-b5e6-96231b3b80d8
makes it into a special member function. This is very bad and can lead
to all sorts of nastiness including implicit member functions violating
the One Definition Rule. This should probably be made ill-formed in a
later version of the standard, but for now we'll just warn.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132104 91177308-0d34-0410-b5e6-96231b3b80d8
behind implicit moves. We now correctly identify move constructors and
assignment operators and update bits on the record correctly. Generation
of implicit moves (declarations or definitions) is not yet supported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132080 91177308-0d34-0410-b5e6-96231b3b80d8
type that turns one type into another. This is used as the basis to
implement __underlying_type properly - with TypeSourceInfo and proper
behavior in the face of templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132017 91177308-0d34-0410-b5e6-96231b3b80d8
that the unevaluated subexpressions of &&, ||, and ? : are not
considered when determining whether the expression is a constant
expression. Also, turn the "used in its own initializer" warning into
a runtime-behavior warning, so that it doesn't fire when a variable is
used as part of an unevaluated subexpression of its own initializer.
Fixes PR9999.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131968 91177308-0d34-0410-b5e6-96231b3b80d8
should use a constructor to default-initialize a
variable. InitializationSequence knows the rules for default
initialization, better. Fixes <rdar://problem/8501008>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131796 91177308-0d34-0410-b5e6-96231b3b80d8
Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.
Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131735 91177308-0d34-0410-b5e6-96231b3b80d8
template<class U>
struct X1 {
template<class T> void f(T*);
template<> void f(int*) { }
};
Won't be so simple. I need to think more about it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131362 91177308-0d34-0410-b5e6-96231b3b80d8
Anders Carlsson
Nick Lewycky
Richard Trieu
Richard Smith
Douglas Gregor
Argyrios Kyrtzidis
Fariborz Jahanian
John McCall
Chris Lattner
Eli Friedman
Francois Pichet
Rafael Espindola
Sean Hunt
Sebastian Redl