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
SVal::GetRValueSymbolVal do the checking if we can symbolicate a type instead of
having BasicStoreManager do it (which wasn't always doing the check
consistently). Having this check in SVal::GetRValueSymbolVal keeps the check in
one centralized place.
llvm-svn: 67245
if our usual methods fail. This isn't necessary for running the tool,
but improves the accuracy of logging output.
Also, have GCC tools lookup gcc program path.
llvm-svn: 67243
and the token after the # should be expanded if it is not a valid directive.
This allows us to transform things like:
#define FOO BAR
# FOO
into # BAR, even though FOO is not normally expanded for directives.
This should fix PR3833
llvm-svn: 67236
- Support things like telling which -ffoo -fno-foo option won, and
forwarding all arguments matching a certain set of options to the
tool.
llvm-svn: 67189
handled by driver.
- This is not very precise, we use it to drive the "forward-to-gcc"
predicate, when trying to talk to a generic gcc tool.
- Slightly better than what ccc was doing, and should be good
enough. Platforms which want a robust driver should implement a
proper tool chain.
llvm-svn: 67181
earlier.
- This gives us a simple ownership model, and allows clients access
to more information should they ever want it.
- We now free Actions correctly.
llvm-svn: 67158
Type pointer. This allows our nested-name-specifiers to retain more
information about the actual spelling (e.g., which typedef did the
user name, or what exact template arguments were used in the
template-id?). It will also allow us to have dependent
nested-name-specifiers that don't map to any DeclContext.
llvm-svn: 67140
a type. For example, if we have a typedef of a typeof of
int, we strip all the say down to int. This allows us to
simplify the getAs* methods, and is the first step towards
fixing PR3817
llvm-svn: 67126
quite as great as it sounds, because, while we can refer to the
enumerator values outside the template, e.g.,
adder<long, 3, 4>::value
we can't yet refer to them with dependent names, so no Fibonacci
(yet).
InstantiateClassTemplateSpecialization is getting messy; next commit
will put it into a less-ugly state.
llvm-svn: 67092
- Slightly strange, but the idea is that the ArgList data structure
is primarily a list of arguments; we want to allow clients to still
add argument strings to an ArgList to avoid worrying about string
lifetimes (or unnecessary string copying).
llvm-svn: 67086
IntegerLiterals during instantiation when we should be creating either
a boolean literal (CXXBoolLiteralExpr) or a character literal
(CharacterLiteral).
llvm-svn: 67061
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
- Still need code for determining proper output location.
- Doesn't work yet, of course, as the host isn't providing real
tool chains.
- Interface still has a few warts, but has gotten a nice bit of
polish during the rewrite.
llvm-svn: 67038
access to most data should go through the current Compilation, not the
Driver (which shouldn't be specialized on variables for a single
compilation).
llvm-svn: 67037
week in:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013580.html
That patch caused the output of the diagnostics to change. Since
'DeclarationName' can already reason about Selectors and the Diagnostics logic
reasons about DeclarationName, there is no additional code needed to get the
diagnostics working by making Selector::getIdentifierInfo() private.
llvm-svn: 66992
Daniel Dunbar