Douglas Gregor [Tue, 30 Jun 2009 23:57:56 +0000 (23:57 +0000)]
When explicit template arguments are provided for a function call,
substitute those template arguments into the function parameter types
prior to template argument deduction. There's still a bit of work to
do to make this work properly when only some of the template arguments
are specified.
Douglas Gregor [Tue, 30 Jun 2009 22:34:41 +0000 (22:34 +0000)]
Preliminary parsing and ASTs for template-ids that refer to function
templates, such as make<int&>. These template-ids are only barely
functional for function calls; much more to come.
Ted Kremenek [Tue, 30 Jun 2009 22:31:23 +0000 (22:31 +0000)]
Update old CastRegion logic to not assume that ElementRegion's super region is a
TypedRegion. While we plan on removing this code at some point, it serves as a
good reference implementation for use with BasicStore until we are sure the new
CastRegion logic (in RegionStore.cpp) is correct.
Douglas Gregor [Tue, 30 Jun 2009 17:20:14 +0000 (17:20 +0000)]
When recursively instantiating function templates, keep track of the
instantiation stack so that we provide a full instantiation
backtrace. Previously, we performed all of the instantiations implied
by the recursion, but each looked like a "top-level" instantiation.
The included test case tests the previous fix for the instantiation of
DeclRefExprs. Note that the "instantiated from" diagnostics still
don't tell us which template arguments we're instantiating with.
Torok Edwin [Tue, 30 Jun 2009 16:30:17 +0000 (16:30 +0000)]
Use templates instead of creating a new class for each OS/Target combination.
This unifies all the targets supported by an OS into a template.
It also cleans up the differences between the darwin targets.
Also __LP64__ wasn't needed for *BSD, since x86-64 target defines it anyway.
Douglas Gregor [Tue, 30 Jun 2009 15:47:41 +0000 (15:47 +0000)]
Refactor ActOnDeclarationNameExpr into a "parsing action" part and a
"semantic analysis" part. Use the "semantic analysis" part when
performing template instantiation on a DeclRefExpr, rather than an ad
hoc list of rules to construct DeclRefExprs from the instantiation.
A test case for this change will come in with a large commit, which
illustrates what I was actually trying to work on.
Zhongxing Xu [Tue, 30 Jun 2009 13:00:53 +0000 (13:00 +0000)]
Instead of r74522, use another approach to fix xfail_regionstore_wine_crash.c.
Mark the super region of the binding of block level expr in the Environment
as live.
Zhongxing Xu [Tue, 30 Jun 2009 12:11:58 +0000 (12:11 +0000)]
Block level expr should be visited. Otherwise variables in init expr of
DeclStmt would be dead before the DeclStmt.
For example:
int x = 0;
int y = x;
'x' would be dead before 'int y = x'.
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
Remove the ASTContext parameter from the attribute-related methods of Decl.
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
Chris Lattner [Tue, 30 Jun 2009 01:26:17 +0000 (01:26 +0000)]
Key decisions about 'bool' vs '_Bool' to be based on a new flag in langoptions.
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
Douglas Gregor [Mon, 29 Jun 2009 22:39:32 +0000 (22:39 +0000)]
Improve code generation for function template specializations:
- Track implicit instantiations vs. the not-yet-supported explicit
specializations
- Give implicit instantiations of function templates (and member
functions of class templates) linkonce_odr linkage.
- Improve name mangling for function template specializations,
including the template arguments of the instantiation and the return
type of the function.
Note that our name-mangling is improved, but not correct: we still
don't mangle substitutions, although the manglings we produce can be
demangled.
Douglas Gregor [Mon, 29 Jun 2009 20:59:39 +0000 (20:59 +0000)]
Keep track of function template specializations, to eliminate
redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.
-Keep a reference to the ASTContext inside the TranslationUnitDecl.
-Introduce Decl::getASTContext() which returns the reference from the TranslationUnitDecl that it is contained in.
The general idea is that Decls can point to their own ASTContext so that it is no longer required to "manually" keep track and make sure that you pass the correct ASTContext to Decls' methods, e.g. methods like Decl::getAttrs should eventually not require a ASTContext parameter.
Bill Wendling [Sun, 28 Jun 2009 07:36:13 +0000 (07:36 +0000)]
Add stack protector support to clang. This generates the 'ssp' and 'sspreq'
function attributes. There are predefined macros that are defined when stack
protectors are used: __SSP__=1 with -fstack-protector and __SSP_ALL__=2 with
-fstack-protector-all.
Nate Begeman [Sun, 28 Jun 2009 02:36:38 +0000 (02:36 +0000)]
OpenCL 1.0 support:
Handle rules for ExtVector + ExtVector and ExtVector + Scalar operations.
Fix problem Eli noticed where we were allowing pointer types to be splatted to
vector elements.
Eli Friedman [Sat, 27 Jun 2009 08:17:02 +0000 (08:17 +0000)]
Fix screwup with my previous patch which broke tests. (The patch is
making sure we return true when annotating a function template with
explicit template arguments, but not when we don't annotate anything.)
Douglas Gregor [Fri, 26 Jun 2009 23:27:24 +0000 (23:27 +0000)]
Set the rest of the flags we need to perform template argument
deduction using a base class of the argument type. No actual
functionality change; this is just a hook.
Douglas Gregor [Fri, 26 Jun 2009 23:10:12 +0000 (23:10 +0000)]
During template argument deduction from a function call, allow
deduction from pointer and pointer-to-member types to work even in the
presence of a qualification conversion (C++ [temp.deduct.type]p3
bullet 2).
Douglas Gregor [Fri, 26 Jun 2009 21:40:05 +0000 (21:40 +0000)]
A little template argument deduction test uncovered an "oops". As part
of template instantiation, we were dropping cv-qualifiers on the
instantiated type in a few places. This change reshuffles the
type-instantiation code a little bit so that there's a single place
where we add qualifiers to the instantiated type, so that we won't end
up with this same bug in the future.
Douglas Gregor [Fri, 26 Jun 2009 20:57:09 +0000 (20:57 +0000)]
Template argument deduction is no longer responsible for checking
non-dependent parameter types. Instead, class template partial
specializations perform a final check of all of the instantiated
arguments. This model is cleaner, and works better for function
templates where the "final check" occurs during overload resolution.
Also, cope with cv-qualifiers when the parameter type was originally a
reference type, so that the deduced argument can be more qualified
than the transformed argument.
Chris Lattner [Fri, 26 Jun 2009 04:45:06 +0000 (04:45 +0000)]
Improve error recovery in C++: when we hit 'implicit int' cases in C++,
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. :)
projects / clang / log