| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Fixes PR10154. Found by parsing MFC 2010 code with clang.
llvm-svn: 133380
|
| |
|
|
| |
llvm-svn: 133346
|
| |
|
|
| |
llvm-svn: 133300
|
| |
|
|
|
|
| |
__bridge_retain as a synonym for __bridge_retained.
llvm-svn: 133295
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 133103
|
| |
|
|
| |
llvm-svn: 132994
|
| |
|
|
|
|
|
| |
- Move the diagnostic to the case statement instead of at the end of the switch
- Add a fix-it hint as to how to fix the compilation error
llvm-svn: 132903
|
| |
|
|
| |
llvm-svn: 132901
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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)'
llvm-svn: 132890
|
| |
|
|
| |
llvm-svn: 132878
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 132868
|
| |
|
|
|
|
| |
properties.
llvm-svn: 132866
|
| |
|
|
|
|
|
| |
It is not a sanctioned keyword and is assumed as default.
// rdar://8790791
llvm-svn: 132753
|
| |
|
|
| |
llvm-svn: 132662
|
| |
|
|
|
|
|
| |
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
llvm-svn: 132612
|
| |
|
|
| |
llvm-svn: 132146
|
| |
|
|
|
|
| |
This will give a better error message for cases such as "namespace foo::bar::baz {}" and a suggested fix-it of "namespace foo { namespace bar { namespace baz {} } }"
llvm-svn: 132138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
typedef int TYPE;
class C {
__if_exists(TYPE) {
TYPE a;
}
__if_not_exists(TYPE) {
this will never be parsed.
}
};
llvm-svn: 132052
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 132017
|
| |
|
|
|
|
|
|
| |
The general out-of-line case (including explicit instantiation mostly
works except that the definition is being lost somewhere between the AST
and CodeGen, so the definition is never emitted.
llvm-svn: 131933
|
| |
|
|
| |
llvm-svn: 131633
|
| |
|
|
| |
llvm-svn: 131270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
llvm-svn: 131228
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
class scope.
This removes 2 errors when parsing MFC code with clang
Example:
class A {
virtual void f() = 0 { }
}
llvm-svn: 131175
|
| |
|
|
|
|
|
| |
modify the semantics slightly to accomodate default constructors (I
hope).
llvm-svn: 131087
|
| |
|
|
|
|
| |
everything inside property() for now while we wait for the BoostPro people to provide a complete patch.
llvm-svn: 131053
|
| |
|
|
| |
llvm-svn: 131050
|
| |
|
|
| |
llvm-svn: 131018
|
| |
|
|
|
|
|
|
|
|
|
|
| |
function definition.
Allow to include or exclude code depending on if a symbol exists or not. Just like a #ifdef but for C/C++ symbols.
More doc: http://msdn.microsoft.com/en-us/library/x7wy9xh3(v=VS.100).aspx
Support at class and namespace scopes will be added later.
llvm-svn: 131014
|
| |
|
|
|
|
|
|
| |
Explictly defaultedness is correctly reflected on the AST, but there are
no changes to how that affects the definition of functions or much else
really.
llvm-svn: 130974
|
| |
|
|
|
|
|
| |
direction and not introduce things in the wrong place three different
times.
llvm-svn: 130968
|
| |
|
|
|
|
| |
template-id in an alias declaration was meant to be a specialization. Use a generic, but more accurate, diagnostic.
llvm-svn: 130961
|
| |
|
|
| |
llvm-svn: 130953
|
| |
|
|
|
|
| |
There's some unused stuff for now.
llvm-svn: 130912
|
| |
|
|
| |
llvm-svn: 130776
|
| |
|
|
| |
llvm-svn: 130775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters on the floor in certain cases:
class X {
template <typename T> friend typename A<T>::Foo;
};
This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.
Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.
llvm-svn: 130772
|
| |
|
|
| |
llvm-svn: 130660
|
| |
|
|
|
|
|
|
|
|
|
| |
As might be surmised from their names, these aren't type traits, they're
expression traits. Amazingly enough, they're expression traits that we
have, and fully implement. These "type" traits are even parsed from the
same tokens as the expression traits. Luckily, the parser only tried the
expression trait parsing for these tokens, so this was all just a pile
of dead code.
llvm-svn: 130643
|
| |
|
|
|
|
| |
identifiers in libc++.
llvm-svn: 130508
|
| |
|
|
|
|
| |
new type trait __is_same
llvm-svn: 130468
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
as a keyword for the __is_signed type trait. Cope with this conflict
via some hackish recovery: if we see a declaration of the form
static const bool __is_signed
then we stop treating __is_signed as a keyword and instead treat it as
an identifier. It's ugly, but it's better than making the __is_signed
type trait conditional on some language flag. Fixes PR9804.
llvm-svn: 130399
|
| |
|
|
| |
llvm-svn: 130377
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines to real types.
Otherwise statements like:
__int64 var = __int64(0);
would be expanded to:
long long var = long long(0);
and fail to compile.
llvm-svn: 130369
|
| |
|
|
|
|
|
|
| |
Patch authored by Sohail Somani.
Provide parsing and AST support for Windows structured exception handling.
llvm-svn: 130366
|
| |
|
|
|
|
|
|
|
|
| |
Patch authored by John Wiegley.
These are array type traits used for parsing code that employs certain
features of the Embarcadero C++ compiler: __array_rank(T) and
__array_extent(T, Dim).
llvm-svn: 130351
|
| |
|
|
|
|
|
|
|
|
| |
Patch authored by John Wiegley.
These type traits are used for parsing code that employs certain features of
the Embarcadero C++ compiler. Several of these constructs are also desired by
libc++, according to its project pages (such as __is_standard_layout).
llvm-svn: 130342
|
| |
|
|
|
|
|
| |
ClassifyName() builds a primary expression, generate one of these
annotation tokens rather than jumping into the parser.
llvm-svn: 130297
|
| |
|
|
| |
llvm-svn: 130295
|
| |
|
|
|
|
|
| |
creating a type-annotation token rather than jumping into the
declaration parsing.
llvm-svn: 130293
|