| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Fixes latent and not-so-latent objc++ and blocks++ bugs.
llvm-svn: 95340
|
| |
|
|
| |
llvm-svn: 95335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ton of potential crashes of the same kind. The fundamental problem is
that type creation was following a dangerous pattern when using its
FoldingSets:
1) Use FindNodeOrInsertPos to see if the type is available
2) If not, and we aren't looking at a canonical type, build the
canonical type
3) Build and insert the new node into the FoldingSet
The problem here is that building the canonical type can, in very rare
circumstances, force the hash table inside the FoldingSet to
reallocate. That invalidates the insertion position we computed in
step 1, and in step 3 we end up inserting the new node into the wrong
place. BOOM!
I've audited all of ASTContext, fixing this problem everywhere I found
it. The vast majority of wrong code was C++-specific (and *ahem*
written by me), so I also audited other major folding sets in the C++
code (e.g., template specializations), but found no other instances of
this problem.
llvm-svn: 95315
|
| |
|
|
| |
llvm-svn: 95291
|
| |
|
|
|
|
|
| |
remove some age-old FIXMEs and C++ workarounds within the
type-compatibility logic.
llvm-svn: 95249
|
| |
|
|
|
|
|
| |
with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.
llvm-svn: 95238
|
| |
|
|
|
|
|
| |
now that the "InBytes" part of the name is implied by the return type, rename
it to getDeclAlign().
llvm-svn: 94681
|
| |
|
|
|
|
|
|
| |
sync compare_and_swap to match them with gcc.
It also fixes a few incorrect argument defitions.
(fixes radar 7540291).
llvm-svn: 94607
|
| |
|
|
|
|
| |
getTypeAlignInChars().
llvm-svn: 94553
|
| |
|
|
|
|
| |
units.
llvm-svn: 94552
|
| |
|
|
|
|
|
|
| |
ObjCObjectPointerType using the allocator associated with ASTContext.
Not only does this fix a memory leak, but it also makes these arrays
BumpPtrAllocated (in the typical case).
llvm-svn: 94090
|
| |
|
|
|
|
|
| |
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
llvm-svn: 93959
|
| |
|
|
| |
llvm-svn: 93726
|
| |
|
|
|
|
|
| |
correctly look through arrays to see cv-qualifiers. Also enhances the routine
for doing this to preserve more type sugaring for diagnostics.
llvm-svn: 93252
|
| |
|
|
|
|
| |
are in characters.
llvm-svn: 93171
|
| |
|
|
|
|
|
|
|
|
| |
"ASTContext::getTypeSize() / 8". Replace [u]int64_t variables with CharUnits
ones as appropriate.
Also rename RawType, fromRaw(), and getRaw() in CharUnits to QuantityType,
fromQuantity(), and getQuantity() for clarity.
llvm-svn: 93153
|
| |
|
|
|
|
| |
ASTContext::hasSameUnqualifiedType() when one of the type is VariableArrayType.
llvm-svn: 92723
|
| |
|
|
| |
llvm-svn: 92715
|
| |
|
|
| |
llvm-svn: 92318
|
| |
|
|
|
|
|
|
|
|
| |
more or less cv-qualified than another during implicit conversion and overload
resolution ([basic.type.qualifier] p5). Factors the logic out of template
deduction and into the ASTContext so it can be shared.
This fixes several aspects of PR5542, but not all of them.
llvm-svn: 92248
|
| |
|
|
| |
llvm-svn: 92246
|
| |
|
|
| |
llvm-svn: 92162
|
| |
|
|
|
|
|
|
| |
for loops. Also do not manually free the Type objects when the
'FreeMemory' flag is set, as they will be deallocated when the
BumpPtrAllocator is destroyed.
llvm-svn: 92047
|
| |
|
|
|
|
| |
avoid #including CharUnits.h in ASTContext.h.
llvm-svn: 91903
|
| |
|
|
| |
llvm-svn: 91189
|
| |
|
|
|
|
| |
recently introduced crash.
llvm-svn: 91070
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers thereof) to their corresponding non-noreturn function
types. This conversion is considered an exact match for
overload-resolution purposes. Note that we are a little more strict
that GCC is, because we encode noreturn in the type system, but that's
a Good Thing (TM) because it does not allow us to pretend that
potentially-returning function pointers are non-returning function
pointers.
Fxies PR5620.
llvm-svn: 90913
|
| |
|
|
| |
llvm-svn: 90745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables,
but the results are imperfect.
For posterity, I did:
cat <<EOF > $cmdfile
s/DeclaratorInfo/TypeSourceInfo/g
s/DInfo/TInfo/g
s/TypeTypeSourceInfo/TypeSourceInfo/g
s/SourceTypeSourceInfo/TypeSourceInfo/g
EOF
find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \;
find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \;
find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \;
llvm-svn: 90743
|
| |
|
|
| |
llvm-svn: 90711
|
| |
|
|
| |
llvm-svn: 90614
|
| |
|
|
|
|
|
| |
leaked data structure than before. This kills off the last remaining
explicit uses of OverloadedFunctionDecl in Sema.
llvm-svn: 90306
|
| |
|
|
|
|
| |
recent change to make SEL a builtin type (fixes radar 7425510).
llvm-svn: 90145
|
| |
|
|
|
|
| |
This fixes pr5611.
llvm-svn: 89895
|
| |
|
|
| |
llvm-svn: 89782
|
| |
|
|
| |
llvm-svn: 89696
|
| |
|
|
|
|
| |
methods. This fixes a crash when writing sizeof(Incomplete&), and lets ASTContext's methods do the right thing for CodeGen, which fixes PR5590.
llvm-svn: 89668
|
| |
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type and fixes a long-standing code gen. crash reported in
at least two PRs and a radar. (radar 7405040 and pr5025).
There are couple of remaining issues that I would like for
Ted. and Doug to look at:
Ted, please look at failure in Analysis/MissingDealloc.m.
I have temporarily added an expected-warning to make the
test pass. This tests has a declaration of 'SEL' type which
may not co-exist with the new changes.
Doug, please look at a FIXME in PCHWriter.cpp/PCHReader.cpp.
I think the changes which I have ifdef'ed out are correct. They
need be considered for in a few Indexer/PCH test cases.
llvm-svn: 89561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
incomplete array initialization, where we have the following in a
template:
int a[] = { 1, 2, something-value-dependent };
// ...
sizeof(a);
The type of "a" appears to be a non-dependent IncompleteArrayType, but
treating it as such makes the sizeof(a) fail at template definition
time. We now correctly handle this by morphing the IncompleteArrayType
into a DependentSizedArrayType with a NULL expression, indicating that
its size has no corresponding expression (and, therefore, the type is
distinct from others).
llvm-svn: 89366
|
| |
|
|
|
|
|
|
|
|
| |
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
|
| |
|
|
|
|
| |
As per Fariborz's suggestion, committed now but can be reverted later if the used flag is problematic for Apple.
llvm-svn: 89134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:
typedef const int CInt;
typedef CInt Self;
Self.isConstQualified() currently returns false!
Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions:
- the "local" version only returns qualifiers on this particular
QualType instance
- the "normal" version that will eventually combine qualifiers from this
QualType instance with the qualifiers on the canonical type to
produce the full set of qualifiers.
This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()
expressions over to
Context.hasSameUnqualifiedType(T1, T2)
llvm-svn: 88969
|
| |
|
|
|
|
| |
compiling C++ and a RecordDecl otherwise.
llvm-svn: 88816
|
| |
|
|
| |
llvm-svn: 87087
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
permits, among other things, ripping apart and reconstructing
templates via partial specialization:
template<typename T>
struct DeepRemoveConst { typedef T type; };
template<typename T>
struct DeepRemoveConst<const T> {
typedef typename DeepRemoveConst<T>::type type;
};
template<template<typename> class TT, typename T>
struct DeepRemoveConst<TT<T> > {
typedef TT<typename DeepRemoveConst<T>::type> type;
};
Also, fix a longstanding thinko in the code handling partial ordering
of class template partial specializations. We were performing the
second deduction without clearing out the results of the first
deduction. It's amazing we got through so much code with such a
horrendous error :(
llvm-svn: 86893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
llvm-svn: 86777
|
| |
|
|
|
|
| |
Patch by Victor Zverovich!
llvm-svn: 86638
|