definition variadic. I'm not completely sure it's legal, but the
standard can be interpreted as making it legal, and gcc seems to think
it's legal, so I didn't add an extension warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72689 91177308-0d34-0410-b5e6-96231b3b80d8
walks through DeclContexts properly, and prints more of the
information available in the AST. The functionality is still available
via -ast-print, -ast-dump, etc., and also via the new member functions
Decl::dump() and Decl::print().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72597 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation of tags local to member functions of class templates
(and, eventually, function templates) works when the tag is defined as
part of the decl-specifier-seq, e.g.,
struct S { T x, y; } s1;
Also, make sure that we don't try to default-initialize a dependent
type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72568 91177308-0d34-0410-b5e6-96231b3b80d8
specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:
1) In C++, one is not allowed to define tag types within a type
specifier (e.g., static_cast<struct S { int x; } *>(0) is
ill-formed) or within the result or parameter types of a
function. We now diagnose this.
2) We can extend DeclGroups to contain information about any tags
that are declared/defined within the declaration specifiers of a
variable, e.g.,
struct Point { int x, y, z; } p;
This will help improve AST printing and template instantiation,
among other things.
3) For C99, we can keep track of whether a tag type is defined
within the type of a parameter, to properly cope with cases like,
e.g.,
int bar(struct T2 { int x; } y) {
struct T2 z;
}
We can also do similar things wherever there is a type specifier,
e.g., to keep track of where the definition of S occurs in this
legal C99 code:
(struct S { int x, y; } *)0
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72555 91177308-0d34-0410-b5e6-96231b3b80d8
an integral constant expression, maintain a cache of the value and the
is-an-ICE flag within the VarDecl itself. This eliminates
exponential-time behavior of the Fibonacci template metaprogram.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72428 91177308-0d34-0410-b5e6-96231b3b80d8
alternatives, but please correct me if I'm wrong.
I eventually plan to assert in mergeTypes that we aren't in C++ mode
because composite types are fundamentally not a part of C++. The
remaining callers for code in the regression tests are
Sema::WarnConflictingTypedMethods and CodeGenFunction::EmitFunctionProlog;
I'm not quite sure what the correct approach is for those callers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71946 91177308-0d34-0410-b5e6-96231b3b80d8
declared as a "class", or vice-versa. This warning is under the
control of -Wmismatched-tags, which is off by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71773 91177308-0d34-0410-b5e6-96231b3b80d8
template<typename T>
struct X {
struct Inner;
};
template struct X<int>::Inner;
This change is larger than it looks because it also fixes some
a problem with nested-name-specifiers and tags. We weren't requiring
the DeclContext associated with the scope specifier of a tag to be
complete. Therefore, when looking for something like "struct
X<int>::Inner", we weren't instantiating X<int>.
This, naturally, uncovered a problem with member pointers, where we
were requiring the left-hand side of a member pointer access
expression (e.g., x->*) to be a complete type. However, this is wrong:
the semantics of this expression does not require a complete type (EDG
agrees).
Stuart vouched for me. Blame him.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71756 91177308-0d34-0410-b5e6-96231b3b80d8
template class X<int>;
This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71608 91177308-0d34-0410-b5e6-96231b3b80d8
Per the FIXME, it might be interesting to track whether the inline keyword
was also used on the method, but for now we don't do this. Testcase pending.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71589 91177308-0d34-0410-b5e6-96231b3b80d8
specialization" within a C++ template, and permit name lookup into the
current instantiation. For example, given:
template<typename T, typename U>
struct X {
typedef T type;
X* x1; // current instantiation
X<T, U> *x2; // current instantiation
X<U, T> *x3; // not current instantiation
::X<type, U> *x4; // current instantiation
X<typename X<type, U>::type, U>: *x5; // current instantiation
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71471 91177308-0d34-0410-b5e6-96231b3b80d8
template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.
As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments.
A TagType is dependent if the declaration it references is dependent.
I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71408 91177308-0d34-0410-b5e6-96231b3b80d8
1. In a struct field redefinition, don't mark the struct erroneous. The
field is erroneous, but the struct is otherwise well formed.
2. Don't emit diagnostics about functions that are known to be broken already.
Either fix is sufficient to silence the second diagnostic in the example,
but the combination is better :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70371 91177308-0d34-0410-b5e6-96231b3b80d8
mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.
As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70292 91177308-0d34-0410-b5e6-96231b3b80d8
that if we're going to print an extension warning anyway,
there's no point to changing behavior based on NoExtensions: it will
only make error recovery worse.
Note that this doesn't cause any behavior change because NoExtensions
isn't used by the current front-end. I'm still considering what to do about
the remaining use of NoExtensions in IdentifierTable.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70273 91177308-0d34-0410-b5e6-96231b3b80d8
before r69391: typedef redefinition is an error by default, but if
*either* the old or new definition are from a system header, we silence
it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70177 91177308-0d34-0410-b5e6-96231b3b80d8
Eli Friedman
Sebastian Redl
Anders Carlsson
Douglas Gregor
Jay Foad
Mike Stump
Chris Lattner
Daniel Dunbar