these are usually because the parser was thoroughly confused. In addition
to typing the value being declared as an int and hoping for the best, we
mark the value as invalid so we don't get chains of errors when it is
used downstream. In C, implicit int actually is valid, so typing the thing
as int is good and marking it invalid is bad. :)
llvm-svn: 74266
nested name specifiers. Now we emit stuff like:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~ ^
instead of:
t.cpp:8:16: error: invalid token after top level declarator
static foo::X P;
^
This is inspired by a really awful error message I got from
g++ when I misspelt diag::kind as diag::Kind.
llvm-svn: 69086
that I noticed working on other things.
Instead of emitting:
t2.cc:1:8: error: use of undeclared identifier 'g'
int x(*g);
^
t2.cc:1:10: error: expected ')'
int x(*g);
^
t2.cc:1:6: note: to match this '('
int x(*g);
^
We now only emit:
t2.cc:1:7: warning: type specifier missing, defaults to 'int'
int x(*g);
^
Note that the example in SemaCXX/nested-name-spec.cpp:f4 is still
not great, we now produce both of:
void f4(undef::C); // expected-error {{use of undeclared identifier 'undef'}} \
expected-error {{variable has incomplete type 'void'}}
The second diagnostic should be silenced by something getting marked invalid.
I don't plan to fix this though.
llvm-svn: 68919
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
a class template. At present, we can only instantiation normal
methods, but not constructors, destructors, or conversion operators.
As ever, this contains a bit of refactoring in Sema's type-checking. In
particular:
- Split ActOnFunctionDeclarator into ActOnFunctionDeclarator
(handling the declarator itself) and CheckFunctionDeclaration
(checking for the the function declaration), the latter of which
is also used by template instantiation.
- We were performing the adjustment of function parameter types in
three places; collect those into a single new routine.
- When the type of a parameter is adjusted, allocate an
OriginalParmVarDecl to keep track of the type as it was written.
- Eliminate a redundant check for out-of-line declarations of member
functions; hide more C++-specific checks on function declarations
behind if(getLangOptions().CPlusPlus).
llvm-svn: 67575
class members to the corresponding in-class declaration.
Diagnose the erroneous use of 'static' on out-of-line definitions of
class members.
llvm-svn: 66740
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?
llvm-svn: 66662
N::X only skips those entities specified in C++ [basic.lookup.qual]p1.
Note that both EDG and GCC currently get this wrong. EDG has confirmed
that the bug will be fixed in a future version.
llvm-svn: 61079
specifiers. Specifically:
* Determine when an out-of-line function definition does not match
any declaration within the class or namespace (including coping
with overloaded functions).
* Complain about typedefs and parameters that have scope specifiers.
* Complain about out-of-line declarations that aren't also
definitions.
* Complain about non-static data members being declared out-of-line.
* Allow cv-qualifiers on out-of-line member function definitions.
llvm-svn: 61058
struct A {
struct B;
};
struct A::B {
void m() {} // Assertion failed: getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."
};
Introduce DeclContext::getLexicalParent which may be different from DeclContext::getParent when nested-names are involved, e.g:
namespace A {
struct S;
}
struct A::S {}; // getParent() == namespace 'A'
// getLexicalParent() == translation unit
llvm-svn: 59650
With this snippet:
void f(a::b);
An assert is hit:
Assertion failed: CachedTokens[CachedLexPos-1].getLocation() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token", file ..\..\lib\Lex\PPCaching.cpp, line 98
Introduce Preprocessor::RevertCachedTokens that reverts a specific number of tokens when backtracking is enabled.
llvm-svn: 59636
