braces. We now build the appropriate fully-structured initializer list
for such things. Per PR3618, verified that we're getting the right
code generation.
llvm-svn: 67353
diagnostics following those notes.
Make exceeding the template instantiation depth a fatal error.
Thanks to Daniel for pointing out the problem!
llvm-svn: 67320
dot-syntax expression after earching the list of protocols
in the qualified-id, must keep searching the protocol list
of each of the protocols in the list.
llvm-svn: 67314
F f;
where F is a typedef of a function type, then the function "f" has a
prototype. This is a slight tweak to Chris's suggested fix in
PR3817. Fixes PR3817 and PR3840.
llvm-svn: 67313
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
llvm-svn: 67308
are forwarded to GCC.
- The later is unfortunate, as it prevents us from generally warning
about anything interesting on platforms that use a generic
toolchain. However, we can't do much better without significantly
complicating things, and generally we should have proper tool chain
definitions.
llvm-svn: 67293
QualifiedNameType and QualifiedDeclRefExpr. We now keep track of the
exact nested-name-specifier spelling for a QualifiedDeclRefExpr, and
use that spelling when printing ASTs. This fixes PR3493.
llvm-svn: 67283
specialization names. This way, we keep track of sugared types like
std::vector<Real>
I believe we are now using QualifiedNameTypes everywhere we can. Next
step: QualifiedDeclRefExprs.
llvm-svn: 67268
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
Ted Kremenek