Douglas Gregor [Wed, 27 May 2009 17:54:46 +0000 (17:54 +0000)]
Simplify, and improve the performance of, template instantiation for
declaration references. The key realization is that dependent Decls,
which actually require instantiation, can only refer to the current
instantiation or members thereof. And, since the current context
during instantiation contains all of those members of the current
instantiation, we can simply find the real instantiate that matches up
with the "current instantiation" template.
Douglas Gregor [Wed, 27 May 2009 17:20:35 +0000 (17:20 +0000)]
Enumeration declarations that were instantiated from an enumeration
within a template now have a link back to the enumeration from which
they were instantiated. This means that we can now find the
instantiation of an anonymous enumeration.
Douglas Gregor [Wed, 27 May 2009 17:07:49 +0000 (17:07 +0000)]
Improve name lookup for and template instantiation of declaration
references. There are several smallish fixes here:
- Make sure we look through template parameter scope when
determining whether we're parsing a nested class (or nested class
*template*). This makes sure that we delay parsing the bodies of
inline member functions until after we're out of the outermost
class (template) scope.
- Since the bodies of member functions are always parsed
"out-of-line", even when they were declared in-line, teach
unqualified name lookup to look into the (semantic) parents.
- Use the new InstantiateDeclRef to handle the instantiation of a
reference to a declaration (in DeclRefExpr), which drastically
simplifies template instantiation for DeclRefExprs.
- When we're instantiating a ParmVarDecl, it must be in the current
instantiation scope, so only look there.
Also, remove the #if 0's and FIXME's from the dynarray example, which
now compiles and executes thanks to Anders and Eli.
Douglas Gregor [Wed, 27 May 2009 05:35:12 +0000 (05:35 +0000)]
Initial stab at a generalized operation for determining the
instantiation of a declaration from the template version (or version
that lives in a template) and a given set of template arguments. This
needs much, much more testing, but it suffices for simple examples
like
Douglas Gregor [Wed, 27 May 2009 05:00:47 +0000 (05:00 +0000)]
Don't drop the computed implicit conversions when building a call to
overloaded operator[] or overloaded postfix unary operator (++,
--). Thanks to Eli for finding this bug!
Douglas Gregor [Tue, 26 May 2009 18:54:04 +0000 (18:54 +0000)]
When evaluating a VarDecl as a constant or determining whether it is
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.
Daniel Dunbar [Tue, 26 May 2009 16:37:37 +0000 (16:37 +0000)]
When trying to pass an argument on the stack, assume LLVM will do the right
thing for non-aggregate types.
- Otherwise we unnecessarily pin values to the stack and currently end up
triggering a backend bug in one case.
- This loose cooperation with LLVM to implement the ABI is pretty ugly.
- <rdar://problem/6918722> [irgen] clang miscompile of many pointer varargs on
x86-64
Chris Lattner [Mon, 25 May 2009 18:23:36 +0000 (18:23 +0000)]
tweak non-null check to put the caret on the function, but underline the
argument. This avoids the argument from being silenced when the argument is
the NULL macro, which is defined in a system header. This also makes the output
a bit nicer, e.g.:
t.c:8:3: warning: null passed to a callee which requires a non-null argument
func1(NULL, cp2, i1);
^ ~~~~
vs something like:
t.c:8:10: warning: argument is null where non-null is required
func1(NULL, cp2, i1);
^
Chris Lattner [Mon, 25 May 2009 18:10:41 +0000 (18:10 +0000)]
move some format group options around in the file. Move NonNull group into
DiagnosticGroups.td, and add it as part of -Wformat (which gets it into -Wall).
Chris Lattner [Mon, 25 May 2009 17:16:10 +0000 (17:16 +0000)]
Fix a couple of bugs:
1. When we accept "#garbage" in asm-with-cpp mode, change the token kind
of the # to unknown so that the preprocessor won't try to process it as
a real #. This fixes a crash on the attached example
2. Fix macro definition extents processing to handle #foo at the end of a
macro to say the definition ends with the foo, not the #.
This is a follow-on fix to r72283, and rdar://6916026
Douglas Gregor [Fri, 22 May 2009 23:47:06 +0000 (23:47 +0000)]
Template instantiation for qualified declaration reference
expressions. We are now missing template instantiation logic for only
three classes of expressions:
- Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
- C++ default argument expressions
- Objective-C expressions
Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.
As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.
Ted Kremenek [Fri, 22 May 2009 22:03:22 +0000 (22:03 +0000)]
Modify begin()/end() for AsmStmt iterators to handle the case when Exprs.empty()
is true. Because of recent changes to llvm::SmallVector, using these iterators
when Exprs was empty would cause an assertion failure.
Douglas Gregor [Fri, 22 May 2009 21:26:58 +0000 (21:26 +0000)]
Add a few tests to ensure that member functions of class templates can
call other member functions of class templates, including after
template instantiation. No functionality change.
Douglas Gregor [Fri, 22 May 2009 21:13:27 +0000 (21:13 +0000)]
Representation of and template instantiation for member
expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.
Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g:
(T(*)(int[x+y]));
is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id,
so unnecessary Action calls are made for an unused (and possibly leaked) "x+y".
Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached,
the context that follows is determined (possibly by parsing a cast-expression),
and then we re-introduce the cached tokens into the token stream and parse them appropriately.
The TokenLexer may encounter annotations if the parser enters them using Preprocessor::EnterTokenStream.
So check for annotation before using the Token's IdentifierInfo.
This patch adds support for sender-aware dispatch in Objective-C for the GNU runtime, when
compiled with -fobjc-sender-dependent-dispatch. This is used in AOP, COP, implementing object
planes, and a few other things.
Patch by David Chisnall.
Daniel Dunbar [Fri, 22 May 2009 19:02:20 +0000 (19:02 +0000)]
Don't warn about -funit-at-a-time, and reject -fno-unit-at-a-time.
- We could just warn about -fno-unit-at-a-time, but in practice people using it
probably aren't going to get what they want out of clang.
Also, use "clang" specified error for unsupported things instead of driver
unsupported error.
(Next runtime only) check to see if class implements forwardInvocation method
and objects of this class are derived from 'NSProxy'.
Under such conditions, which means that every method possible is
implemented in the class, we should not issue "Method definition not found"
warnings.
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and
a paren expression without considering the context past the parentheses.
projects / clang / log