Bob Wilson [Fri, 12 Nov 2010 17:24:52 +0000 (17:24 +0000)]
Increase VectorTypeBitfields::VecKind field from 2 to 3 bits.
With the addition of 2 enum values for Neon vectors, this field must now
hold 6 different values and so requires 3 bits. Make the NumElements field
one bit smaller to compensate.
John McCall [Fri, 12 Nov 2010 08:19:04 +0000 (08:19 +0000)]
Replace one hack with a different hack: strip out the ObjectType
parameters to the Transform*Type functions and instead call out
the specific cases where an object type and the unqualified lookup
results are important. Fixes an assert and failed compile on
a testcase from PR7248.
Douglas Gregor [Fri, 12 Nov 2010 07:15:47 +0000 (07:15 +0000)]
Make sure to always check the result of
SourceManager::getPresumedLoc(), so that we don't try to make use of
an invalid presumed location. Doing so can cause crashes.
Ted Kremenek [Fri, 12 Nov 2010 04:25:07 +0000 (04:25 +0000)]
Fix use of an uninitialized SourceLocation because DeclarationNameLoc failed to completely zero-initialize itself.
Now we explicitly memset all of its values.
This bug was uncovered by the 'Index/recursive-cxx-member-calls.cpp', which exhibited an assertion
on an i386 darwin build of clang. Adding this test case back since the assertion is now resolved.
Douglas Gregor [Fri, 12 Nov 2010 03:34:06 +0000 (03:34 +0000)]
When performing initialization of a copy of a temporary object, use
direct-initialization (rather than copy-initialization) to initialize
the temporary, allowing explicit constructors. Fixes PR8342.
Ted Kremenek [Thu, 11 Nov 2010 23:10:10 +0000 (23:10 +0000)]
RegionStore/BasicStore: do not return UndefinedVal for accesses to concrete addresses; instead return UnknownVal. This
leads it up to checkers (e.g., DereferenceChecker) to guard against illegal accesses (e.g., null dereferences).
Douglas Gregor [Thu, 11 Nov 2010 20:45:16 +0000 (20:45 +0000)]
Teach debug-info generation that SourceManager::getPresumedLoc() can
produce an invalid location even when given a valid location, if the
file system has changed underneath us. Recovery more gracefully.
Ted Kremenek [Thu, 11 Nov 2010 08:05:23 +0000 (08:05 +0000)]
Annotate tokens in a separate thread to avoid blowing out stack space. While the CursorVisitor
is gradually becoming more data recursive, AnnotateTokensVisitor does its own recursive call
within the visitor that can still blow out the stack. This can potentially be reworked to avoid this,
but for now just do token annotation on a separate thread.
Ted Kremenek [Thu, 11 Nov 2010 08:05:18 +0000 (08:05 +0000)]
Generalize data-recursive visitation in CursorVisitor to also handle MemberExprs
and CXXCallMemberExprs. This scheme is hopefully general enough to extend to the
rest of the visitor if necessary.
Douglas Gregor [Thu, 11 Nov 2010 00:39:14 +0000 (00:39 +0000)]
Improve ASTUnit's capture of diagnostics so that the
diagnostic-capturing client lives as long as the ASTUnit itself
does. Otherwise, we can end up with crashes when we get a diagnostic
outside of parsing/code completion. The circumstances under which this
happen are really hard to reproduce, because a file needs to change
from under us.
John McCall [Wed, 10 Nov 2010 23:38:19 +0000 (23:38 +0000)]
When -Wconversion computes the range of a type, it uses the (bit-)range
of the enumerators rather than the actual expressible range. This is
great when dealing with opaque *values* of that type, but when computing
the range of the type for purposes of converting *into* it, it produces
warnings in cases we don't care about (e.g. enum_t x = 500;). Divide
the logic into these two cases and use the more conservative range for
targets.
Bob Wilson [Wed, 10 Nov 2010 21:56:12 +0000 (21:56 +0000)]
Add a variant of GCC-style vector types for ARM NEON.
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
Douglas Gregor [Wed, 10 Nov 2010 19:44:59 +0000 (19:44 +0000)]
Instantiate class member template partial specialization declarations
in the order they occur within the class template, delaying
out-of-line member template partial specializations until after the
class has been fully instantiated. This fixes a regression introduced
by r118454 (itself a fix for PR8001).
John McCall [Wed, 10 Nov 2010 07:01:40 +0000 (07:01 +0000)]
Propagate the deprecated and unavailable attributes from a
@property declaration to the autogenerated methods. I'm uncertain
whether this should apply to attributes in general, but these are
a reasonable core.
Ted Kremenek [Wed, 10 Nov 2010 05:59:39 +0000 (05:59 +0000)]
Region-allocate all AttributeList objects from a factory object instead of manually managing them
using new/delete and OwningPtrs. After memory profiling Clang, I witnessed periodic leaks of these
objects; digging deeper into the code, it was clear that our management of these objects was a mess. The ownership rules were murky at best, and not always followed. Worse, there are plenty of error paths where we could screw up.
This patch introduces AttributeList::Factory, which is a factory class that creates AttributeList
objects and then blows them away all at once. While conceptually simple, most of the changes in
this patch just have to do with migrating over to the new interface. Most of the changes have resulted in some nice simplifications.
This new strategy currently holds on to all AttributeList objects during the lifetime of the Parser
object. This is easily tunable. If we desire to have more bound the lifetime of AttributeList
objects more precisely, we can have the AttributeList::Factory object (in Parser) push/pop its
underlying allocator as we enter/leave key methods in the Parser. This means that we get
simple memory management while still having the ability to finely control memory use if necessary.
Note that because AttributeList objects are now BumpPtrAllocated, we may reduce malloc() traffic
in many large files with attributes.
This fixes the leak reported in: <rdar://problem/8650003>
Douglas Gregor [Tue, 9 Nov 2010 20:03:54 +0000 (20:03 +0000)]
Revert the fix for PR8013.
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
Charles Davis [Tue, 9 Nov 2010 18:04:24 +0000 (18:04 +0000)]
Use the right calling convention when mangling names in the Microsoft C++
mangler. Now member functions and pointers thereof have their calling
convention mangled as __thiscall if they have the default CC (even though,
they technically still have the __cdecl CC).
Douglas Gregor [Tue, 9 Nov 2010 06:24:54 +0000 (06:24 +0000)]
ntroduce clang_getSpellingLocation() into libclang, to provide the
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Take 2: this time, adjusted tests appropriately and used a "simple"
approach to the spelling location.
Douglas Gregor [Tue, 9 Nov 2010 05:28:47 +0000 (05:28 +0000)]
Introduce clang_getSpellingLocation() into libclang, to provide the
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Douglas Gregor [Tue, 9 Nov 2010 03:59:40 +0000 (03:59 +0000)]
Teach code completion not to include out-of-line declarations and
definitions in its results. The original declarations will be visible
wherever they are declared.
John McCall [Tue, 9 Nov 2010 01:18:05 +0000 (01:18 +0000)]
When re-using a vtable slot for the nearest overridden method, just because
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider. This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method. Do the appropriate return adjustment in this case.
Nick Lewycky [Tue, 9 Nov 2010 00:19:31 +0000 (00:19 +0000)]
Fix warning about unused variable 'Fn' in no-asserts builds. Also reflow this
block so that it looks more like the rest of the file. No functional change.
projects / clang / log