| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67685 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
line decls, such as:
class C {
C() { }
int a;
};
C::C() : a(10) { }
We also diagnose when initializers are used on declarations that aren't constructors:
t.cpp:1:10: error: only constructors take base initializers
void f() : a(10) { }
^
Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
failure to perform a declaration. Instead, explicitly note semantic
failures that occur during template parsing with a DeclResult. Fixes
PR3872.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
far better error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67495 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
used for the __is_abstract type trait.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
simplify the parsing and action interface for designated
initializers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67415 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
whose sema decl is at the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67249 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics. This builds on the patch that Sebastian committed and
then revert. Major differences are:
- We don't remove or use the current ".def" files. Instead, for now,
we just make sure that we're building the ".inc" files.
- Fixed CMake makefiles to run TableGen and build the ".inc" files
when needed. Tested with both the Xcode and Makefile generators
provided by CMake, so it should be solid.
- Fixed normal makefiles to handle out-of-source builds that involve
the ".inc" files.
I'll send a separate patch to the list with Sebastian's changes that
eliminate the use of the .def files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67033 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PrintParserCallbacks a bit more in line with reality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67029 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66983 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the selector for the property setter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
aren't very pretty:-(
This fixes <rdar://problem/6496506> Implement class setter/getter for properties.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration parsing. Fixes PR3680
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Also, diagnose weak applied to types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Introduce a new PrettyStackTraceDecl.
Use it to add the top level LLVM IR generation stuff in
Backend.cpp to stack traces. We now get crashes like:
Stack dump:
0. Program arguments: clang t.c -emit-llvm
1. <eof> parser at end of file
2. t.c:1:5: LLVM IR generation of declaration 'a'
Abort
for IR generation crashes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66153 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
token.
For example:
Stack dump:
0. Program arguments: clang t.cpp
1. t.cpp:4:8: current parser token: ';'
2. t.cpp:3:1: parsing struct/union/class body 'x'
Abort
It is weird that the parser is always "underneath" any parse context
actions, but the parser is created first.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66148 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
gives us:
Stack dump:
0. using-directive.cpp:26:16: in compound statement ('{}')
1. using-directive.cpp:26:16: parsing function body 'A::K1::foo'
2. using-directive.cpp:25:3: parsing struct/union/class body 'A::K1'
3. using-directive.cpp:5:1: parsing namespace 'A'
4. clang using-directive.cpp
Abort
for code like:
namespace A {
...
class K1 {
void foo() { <<crash>>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66124 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
like this:
Stack dump:
0. using-directive.cpp:9:14: in compound statement ('{}')
1. using-directive.cpp:9:14: parsing function body 'A::B::f'
2. using-directive.cpp:7:3: parsing namespace 'A::B'
3. using-directive.cpp:5:1: parsing namespace 'A'
4. clang using-directive.cpp
Abort
for testcase like like:
namespace A {
short i;
namespace B {
long i;
void f() { <<crash>>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66123 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Stack dump:
0. message.m:53:13: in compound statement ('{}')
1. message.m:53:13: parsing Objective-C method 'xx'
2. clang message.m
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66121 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
like:
Stack dump:
0. t.c:5:10: in compound statement ('{}')
1. t.c:3:12: in compound statement ('{}')
2. t.c:3:12: parsing function body 'foo'
3. clang t.c
Abort
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66118 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
locations that are the current tok loc. Note that inline C++ methods
have a big fixme that could cause a crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parser. For example, we now print out:
0. t.c:5:10: in compound statement {}
1. t.c:3:12: in compound statement {}
2. clang t.c -fsyntax-only
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
c-style functions declared inside objc @implementations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66087 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
multiple sequential case statements instead of doing it with recursion. This
fixes a problem where we run out of stack space parsing 100K directly nested
cases.
There are a couple other problems that prevent this from being useful in
practice (right now the example only parses correctly with -disable-free and
doesn't work with -emit-llvm), but this is a start.
I'm not including a testcase because it is large and uninteresting for
regtesting.
Sebastian, I would appreciate it if you could scrutinize the smart pointer
gymnastics I do.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66011 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(Daniel, please verify).
Also necessary to fix:
<rdar://problem/6632061> [sema] non object types should not be allowed in @catch statements
<rdar://problem/6252237> [sema] qualified id should be disallowed in @catch statements
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Parser::ParseObjCMethodDefinition(): Make sure we don't exit the BodyScope until ActOnFinishFunctionBody() is complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65880 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65646 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65645 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
useless to something more vague but hopefully more clear.
rdar://6624173
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
derive from a class template specialization, e.g.,
class B : public A<int> { };
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vector<vector<double>> Matrix;
In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.
In C++0x, this token is always broken into two '>' tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
zero expression arguments. This eliminates 2579 1-byte
mallocs when parsing Cocoa.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65022 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64961 91177308-0d34-0410-b5e6-96231b3b80d8
|
