Douglas Gregor [Mon, 9 Feb 2009 23:23:08 +0000 (23:23 +0000)]
Rudimentary checking of template arguments against their corresponding
template parameters when performing semantic analysis of a template-id
naming a class template specialization.
Douglas Gregor [Mon, 9 Feb 2009 21:04:56 +0000 (21:04 +0000)]
Implement Sebastian's idea for simplifying our handling of the greater-than operator/delimiter. Also, clean up after ourselves following a failed parse of a template-argument-list
Douglas Gregor [Mon, 9 Feb 2009 19:45:19 +0000 (19:45 +0000)]
When handling "the rest" of a designated array subobject, maybe sure
to tell it that it wasn't (directly) designated. This way, we unwind
back to the explicit initializer list properly rather than getting
stuck in the wrong subobject. Fixes llvm.org/PR3519
Douglas Gregor [Mon, 9 Feb 2009 19:34:22 +0000 (19:34 +0000)]
Eliminate TemplateArg so that we only have a single kind of
representation for template arguments. Also simplifies the interface
for ActOnClassTemplateSpecialization and eliminates some annoying
allocations of TemplateArgs.
My attempt at smart pointers for template arguments lists is
relatively lame. We can improve it once we're sure that we have the
right representation for template arguments.
Douglas Gregor [Mon, 9 Feb 2009 18:46:07 +0000 (18:46 +0000)]
Start processing template-ids as types when the template-name refers
to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:
- Parse template-ids like 'vector<int>' (where 'vector' names a
class template) and form proper types for them in the type system.
- Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
using (sadly) a bool in the parser to tell it whether '>' should
be treated as an operator or not.
This is a baby-step, with major problems and limitations:
- There are currently two ways that we handle template arguments
(whether they are types or expressions). These will be merged, and,
most likely, TemplateArg will disappear.
- We don't have any notion of the declaration of class template
specializations or of template instantiations, so all template-ids
are fancy names for 'int' :)
Douglas Gregor [Mon, 9 Feb 2009 15:09:02 +0000 (15:09 +0000)]
Make Sema::getTypeName return the opaque pointer of a QualType rather
than a Decl, which gives us some more flexibility to express the
results with the type system. There are no clients using this
flexibility yet, but it's meant to be able to describe qualified names
as written in the source (e.g., "foo::type") or template-ids that name
a class template specialization (e.g., "std::vector<INT>").
DeclSpec's TST_typedef has become TST_typename, to reflect its use to
describe types found by name (that may or may not be typedefs). The
type representation of a DeclSpec with TST_typename is an opaque
QualType pointer. All users of TST_typedef, both direct and indirect,
have been updated for these changes.
Mike Stump [Sun, 8 Feb 2009 09:22:19 +0000 (09:22 +0000)]
Wire up break and continue processing to the new stack depth adjuster.
If people could beat on it and let me know if there are any new
semantics required by newer language standards or DRs or any little
details I goofed on, I'd be happy to fix any issues found.
Chris Lattner [Sun, 8 Feb 2009 00:55:22 +0000 (00:55 +0000)]
Genericize the existing logic for removing duplicate header dirs to apply
the "system dirs win over user dirs" logic to framework and headermap
search locations as well as normal directories. This means that
clang t.m -F/System/Library/Frameworks will treat /System/Library/Frameworks
as a system directory not a user directory. If you use -v, the difference is:
After:
ignoring nonexistent directory "/usr/libdata/gcc41"
ignoring duplicate directory "/System/Library/Frameworks"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
Mike Stump [Sat, 7 Feb 2009 23:02:10 +0000 (23:02 +0000)]
Ensure we track all the stack depths for all break and continue points
correctly. This should lay the ground work to throw the big switch
and start code gening break and continue in the presense of vlas.
Ted Kremenek [Sat, 7 Feb 2009 22:19:59 +0000 (22:19 +0000)]
Determining the allocation site for a leak when constructing a CFRefLeakReport. This avoids repeated calls to GetAllocationSite when Profiling a CFRefLeakReport object.
Mike Stump [Sat, 7 Feb 2009 20:09:00 +0000 (20:09 +0000)]
Ensure that we don't miscodegen if vlas creap into the top of the for.
This will allow us to generate break and continue even if vlas are
involved without worry that we'll silently generate bad code.
Chris Lattner [Sat, 7 Feb 2009 06:38:06 +0000 (06:38 +0000)]
make sure that UINTMAX_MAX has an unsigned type. This assumes that
uintmax_t is unsigned long long, which is not optimal, but is assumed
elsewhere already.
Daniel Dunbar [Sat, 7 Feb 2009 02:46:03 +0000 (02:46 +0000)]
Set load/store alignment when doing ABI coercions.
- Currently, this is producing poor code, but we prefer correctness
to performance for now. Eventually we should be able to generally
avoid having to set the alignment when we control the alignment of
the alloca.
- This knocks out 33/1000 failures on my single argument ABI tests,
down to 22/1000 and 18 of these appear to be gcc bugs. Woot.
Ted Kremenek [Sat, 7 Feb 2009 01:47:29 +0000 (01:47 +0000)]
Overhaul of Stmt allocation:
- Made allocation of Stmt objects using vanilla new/delete a *compiler
error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
operator that takes ASTContext& as an argument. This ensures that
all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
AST nodes use new (ASTContext&). This is a large patch, but the
majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
deallocated using 'delete'. Instead, one most do
StmtObject->Destroy(ASTContext&) or do
ASTContextObject.Deallocate(StmtObject) (the latter not running the
'Destroy' method).
Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
ASTContext (previously it used std::vector). There are a whole
bunch of other Stmt classes that need to be similarly changed to
ensure that all memory allocated for ASTs comes from the allocator
in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h. This replaces
the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
'delete' to free memory instead of a Stmt's 'Destroy' method.
Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!
Ted Kremenek [Sat, 7 Feb 2009 00:52:24 +0000 (00:52 +0000)]
GRExprEngine: When processing compound assignments, do a switch table lookup to get the non-compound opcode from the compound opcode instead of relying on the order of BinaryOperator::opcode values. This unbreaks the misc-ps.c test.
Chris Lattner [Sat, 7 Feb 2009 00:23:17 +0000 (00:23 +0000)]
Apparently it is important to define intptr_t and uintptr_t to
long instead of int. This is because system heaers like to redefine
typedefs and that is an error if they don't exactly match. Use long
for intptr_t on all systems where long is the right size.
Chris Lattner [Fri, 6 Feb 2009 23:29:39 +0000 (23:29 +0000)]
only define MB_LEN_MAX if the system <limits.h> doesn't.
don't typecast CHAR_MIN to char, this makes it not a PP constant
and gives it the wrong unpromoted type. Thanks to Sebastian for
pointing this out!
projects / clang / log