| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 140293
|
| |
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
| |
|
|
| |
llvm-svn: 139599
|
| |
|
|
|
|
| |
must also be present of the first declaration of that entity.
llvm-svn: 139384
|
| |
|
|
|
|
|
| |
indicates that a declaration is only visible within the module it is
declared in.
llvm-svn: 139348
|
| |
|
|
|
|
| |
This patch was written by DeLesley Hutchins.
llvm-svn: 139302
|
| |
|
|
|
|
|
|
| |
class scope.
This patch was also written by DeLesley Hutchins.
llvm-svn: 139301
|
| |
|
|
|
|
|
| |
Objective-C. The @encode'ing of such an enumeration type is the same
as its underlying type. <rdar://problem/5276348>.
llvm-svn: 139297
|
| |
|
|
|
|
| |
C++98: permit it within type-ids.
llvm-svn: 139103
|
| |
|
|
|
|
| |
for-range and auto with an ExtWarn, and produce a -Wc++0x-compat warning in C++98 mode when auto is used as a storage class.
llvm-svn: 139102
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
|
| |
|
|
|
|
|
| |
objective-c containers due to recent changes to objc decl
contexts. // rdar://10041908
llvm-svn: 138803
|
| |
|
|
|
|
| |
Patch by Chris Cudmore!
llvm-svn: 138533
|
| |
|
|
|
|
| |
failures are resolved.
llvm-svn: 138234
|
| |
|
|
| |
llvm-svn: 138049
|
| |
|
|
|
|
|
|
|
|
| |
to modernity. Instead of passing down individual
context objects from parser to sema, establish decl
context in parser and have sema access current context
as needed. I still need to take of Doug's comment for
minor cleanups.
llvm-svn: 138040
|
| |
|
|
|
|
|
|
| |
in 64-bit mode (ie: when _M_IA64 or _M_AMD64 is defined)
more info: http://msdn.microsoft.com/en-us/library/ms177389.aspx
llvm-svn: 137935
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
|
| |
|
|
|
|
| |
David Blaikie!
llvm-svn: 136876
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
|
|
| |
parsing lambda expressions, from John Freeman!
llvm-svn: 135090
|
| |
|
|
|
|
|
| |
of an enum specifier in dialects which permit fixed underlying types.
Fixes the rejects-valid part of PR10264.
llvm-svn: 134468
|
| |
|
|
|
|
| |
repetition and better reflect the actual grammar, from John Freeman!
llvm-svn: 134417
|
| |
|
|
|
|
| |
classes, the tag types need to have an associated access specifier, and inside function definitions, they need to be included in the declarations of the DeclStmt. These issues manifested as assertions during template instantiation, and also in a WIP constexpr patch.
llvm-svn: 134250
|
| |
|
|
|
|
|
|
|
|
| |
resources that, while their
lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak.
Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138.
llvm-svn: 133610
|
| |
|
|
|
|
| |
Fixes PR10154. Found by parsing MFC 2010 code with clang.
llvm-svn: 133380
|
| |
|
|
|
|
|
|
|
|
| |
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: 132662
|
| |
|
|
| |
llvm-svn: 131633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
everything inside property() for now while we wait for the BoostPro people to provide a complete patch.
llvm-svn: 131053
|
| |
|
|
| |
llvm-svn: 131018
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
There's some unused stuff for now.
llvm-svn: 130912
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 130295
|
| |
|
|
|
|
|
| |
creating a type-annotation token rather than jumping into the
declaration parsing.
llvm-svn: 130293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performs name lookup for an identifier and resolves it to a
type/expression/template/etc. in the same step. This scheme is
intended to improve both performance (by reducing the number of
redundant name lookups for a given identifier token) and error
recovery (by giving Sema a chance to correct type names before the
parser has decided that the identifier isn't a type name). For
example, this allows us to properly typo-correct type names at the
beginning of a statement:
t.c:6:3: error: use of undeclared identifier 'integer'; did you mean
'Integer'?
integer *i = 0;
^~~~~~~
Integer
t.c:1:13: note: 'Integer' declared here
typedef int Integer;
^
Previously, we wouldn't give a Fix-It because the typo correction
occurred after the parser had checked whether "integer" was a type
name (via Sema::getTypeName(), which isn't allowed to typo-correct)
and therefore decided to parse "integer * i = 0" as an expression. By
typo-correcting earlier, we typo-correct to the type name Integer and
parse this as a declaration.
Moreover, in this context, we can also typo-correct identifiers to
keywords, e.g.,
t.c:7:3: error: use of undeclared identifier 'vid'; did you mean
'void'?
vid *p = i;
^~~
void
and recover appropriately.
Note that this is very much a work-in-progress. The new
Sema::ClassifyName is only used for expression-or-declaration
disambiguation in C at the statement level. The next steps will be to
make this work for the same disambiguation in C++ (where
functional-style casts make some trouble), then push it
further into the parser to eliminate more redundant name lookups.
Fixes <rdar://problem/7963833> for C and starts us down the path of
<rdar://problem/8172000>.
llvm-svn: 130082
|
| |
|
|
|
|
| |
tag name. Fixes rdar://9295072
llvm-svn: 129917
|
| |
|
|
|
|
| |
// rdar://9132143
llvm-svn: 129822
|
| |
|
|
| |
llvm-svn: 129555
|
| |
|
|
|
|
| |
draft standard (N3291).
llvm-svn: 129541
|
| |
|
|
|
|
| |
for them. The only major missing feature is references.
llvm-svn: 129234
|
| |
|
|
|
|
|
| |
'unavailable' argument, which specifies that the declaration to which
the attribute appertains is unavailable on that platform.
llvm-svn: 128329
|
| |
|
|
|
|
|
|
|
| |
AttributeLists do not accumulate over the lifetime of parsing, but are
instead reused. Also make the arguments array not require a separate
allocation, and make availability attributes store their stuff in
augmented memory, too.
llvm-svn: 128209
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
|
| |
|
|
|
|
|
|
|
| |
add support for the OpenCL __private, __local, __constant and
__global address spaces, as well as the __read_only, _read_write and
__write_only image access specifiers. Patch originally by ARM;
language-specific address space support by myself.
llvm-svn: 127915
|
| |
|
|
| |
llvm-svn: 127755
|