| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 67800
|
| |
|
|
|
|
|
|
| |
all the way down to ActOnClassTemplate.
Doug, Sebastian: Plz review! :)
llvm-svn: 67723
|
| |
|
|
| |
llvm-svn: 67710
|
| |
|
|
| |
llvm-svn: 67685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 67672
|
| |
|
|
|
|
|
|
| |
failure to perform a declaration. Instead, explicitly note semantic
failures that occur during template parsing with a DeclResult. Fixes
PR3872.
llvm-svn: 67659
|
| |
|
|
| |
llvm-svn: 67653
|
| |
|
|
| |
llvm-svn: 67626
|
| |
|
|
| |
llvm-svn: 67625
|
| |
|
|
| |
llvm-svn: 67624
|
| |
|
|
| |
llvm-svn: 67569
|
| |
|
|
|
|
| |
far better error recovery.
llvm-svn: 67495
|
| |
|
|
|
|
| |
used for the __is_abstract type trait.
llvm-svn: 67461
|
| |
|
|
|
|
|
| |
simplify the parsing and action interface for designated
initializers.
llvm-svn: 67415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67265
|
| |
|
|
|
|
| |
whose sema decl is at the translation unit.
llvm-svn: 67249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67058
|
| |
|
|
| |
llvm-svn: 67033
|
| |
|
|
| |
llvm-svn: 67031
|
| |
|
|
|
|
| |
PrintParserCallbacks a bit more in line with reality.
llvm-svn: 67029
|
| |
|
|
| |
llvm-svn: 66983
|
| |
|
|
|
|
| |
the selector for the property setter.
llvm-svn: 66834
|
| |
|
|
| |
llvm-svn: 66661
|
| |
|
|
| |
llvm-svn: 66551
|
| |
|
|
|
|
|
|
| |
aren't very pretty:-(
This fixes <rdar://problem/6496506> Implement class setter/getter for properties.
llvm-svn: 66465
|
| |
|
|
|
|
| |
declaration parsing. Fixes PR3680
llvm-svn: 66305
|
| |
|
|
|
|
| |
- Also, diagnose weak applied to types.
llvm-svn: 66259
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 66153
|
| |
|
|
| |
llvm-svn: 66150
|
| |
|
|
| |
llvm-svn: 66149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 66148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>>
llvm-svn: 66124
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>>
llvm-svn: 66123
|
| |
|
|
|
|
|
|
|
| |
Stack dump:
0. message.m:53:13: in compound statement ('{}')
1. message.m:53:13: parsing Objective-C method 'xx'
2. clang message.m
llvm-svn: 66121
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 66118
|
| |
|
|
|
|
|
| |
locations that are the current tok loc. Note that inline C++ methods
have a big fixme that could cause a crash.
llvm-svn: 66113
|
| |
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 66108
|
| |
|
|
|
|
| |
c-style functions declared inside objc @implementations.
llvm-svn: 66087
|
| |
|
|
| |
llvm-svn: 66044
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 66011
|
| |
|
|
|
|
|
|
|
|
|
| |
(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
llvm-svn: 65964
|
| |
|
|
|
|
| |
Parser::ParseObjCMethodDefinition(): Make sure we don't exit the BodyScope until ActOnFinishFunctionBody() is complete.
llvm-svn: 65880
|
| |
|
|
| |
llvm-svn: 65695
|
| |
|
|
| |
llvm-svn: 65646
|
| |
|
|
| |
llvm-svn: 65645
|
| |
|
|
| |
llvm-svn: 65641
|
| |
|
|
|
|
|
| |
useless to something more vague but hopefully more clear.
rdar://6624173
llvm-svn: 65639
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 65570
|
| |
|
|
|
|
|
|
| |
derive from a class template specialization, e.g.,
class B : public A<int> { };
llvm-svn: 65488
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 65484
|