| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 141610
|
|
|
|
|
|
|
| |
declarator, so that the declarator is in scope for the
initializer. Fixes PR9989.
llvm-svn: 141539
|
|
|
|
| |
llvm-svn: 141411
|
|
|
|
|
|
| |
attributes on the parameter declaration.
llvm-svn: 140944
|
|
|
|
|
|
|
| |
support for the C++0x draft [[align]] attribute and add the C1X
standard header file stdalign.h
llvm-svn: 140796
|
|
|
|
|
|
| |
attribute-specifiers
llvm-svn: 140794
|
|
|
|
|
|
| |
from Stepan Dyatkovskiy. Fixes PR10925.
llvm-svn: 140528
|
|
|
|
|
|
|
|
|
|
|
| |
correctly pass
the information on to Sema. There's still an incorrectness in the way template instantiation
works now, but that is due to a far larger underlying representational problem.
Also add a test case for various list initialization cases of scalars, which test this
commit as well as the previous one.
llvm-svn: 140460
|
|
|
|
| |
llvm-svn: 140389
|
|
|
|
|
|
|
|
| |
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: 139406
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
class scope.
This patch was also written by DeLesley Hutchins.
llvm-svn: 139301
|
|
|
|
|
|
|
|
| |
Fix bug this uncovered.
Address minor comments from Doug.
Enable cxx_implicit_moves feature.
llvm-svn: 139101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
a context switching object.
llvm-svn: 138248
|
|
|
|
|
|
| |
failures are resolved.
llvm-svn: 138234
|
|
|
|
| |
llvm-svn: 137653
|
|
|
|
|
|
| |
David Blaikie!
llvm-svn: 136876
|
|
|
|
|
|
|
| |
libstdc++ hack has reverted these type traits to keywords. Icky, but
fixes <rdar://problem/9836262>.
llvm-svn: 136560
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
|
|
|
|
| |
also contain declarators. Previously we would accept code like this:
template<typename T> struct S { } f() { return 0; }
This case now produces a missing ';' diagnostic, since that seems like a much more likely error than an attempt to declare a function or variable in addition to the class template.
Treat this
llvm-svn: 135195
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
declaration, determine whether the declaration will end up declaring a
function using semantic criteria (e.g., it will have function type)
rather than purely syntactic criteria (e.g., it has the form of a
function declarator). Fixes <rdar://problem/9670557>.
llvm-svn: 133854
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 132662
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class scope.
This removes 2 errors when parsing MFC code with clang
Example:
class A {
virtual void f() = 0 { }
}
llvm-svn: 131175
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
identifiers in libc++.
llvm-svn: 130508
|
|
|
|
|
|
| |
new type trait __is_same
llvm-svn: 130468
|
|
|
|
|
|
|
|
| |
Patch authored by Sohail Somani.
Provide parsing and AST support for Windows structured exception handling.
llvm-svn: 130366
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
when parsing global decls. It's still rather broken (skipping much too far when the declarator belongs to a function definition), but at least not so broken as to mismatch braces. Tested by the removal of the fixme in the template test case.
llvm-svn: 130101
|
|
|
|
| |
llvm-svn: 129567
|