claim this is C. We don't make ElaboratedTypes in C, but sometimes
the language options during pretty-print lie to us.
The rewriter should really be fixed to not rely on how types are pretty-printed,
though.
llvm-svn: 98189
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
that are hidden by other derived base subobjects reached along a
lookup path that does *not* pass through the hiding subobject (C++
[class.member.lookup]p6). Fixes PR6462.
llvm-svn: 97640
category. Use this in a few places to eliminate unnecessary TST cases and
do some future-proofing. Provide terrible manglings for typeof. Mangle
decltype with some hope of accuracy.
Our manglings for some of the cases covered in the testcase are different
from gcc's, which I've raised as an issue with the ABI list.
llvm-svn: 97523
how we find the operator delete that matches withe operator new we
found in a C++ new-expression.
This will also need CodeGen support. On a happy note, we're now a
"nans" away from building tramp3d-v4.
llvm-svn: 97209
expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
llvm-svn: 97092
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
llvm-svn: 97079
__alignof__ operator, make sure to take into account the packed alignment
of the struct/union/class itself. Matches GCC's behavior and fixes PR6362.
llvm-svn: 96884
1) emit base destructors as aliases to their unique base class destructors
under some careful conditions. This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.
2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor. This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).
These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.
llvm-svn: 96842
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
llvm-svn: 96766
are for out of line declarations more easily. This simplifies the logic and
handles the case of out-of-line class definitions correctly. Fixes PR6107.
llvm-svn: 96729
to initializer expressions in an array allocated using ASTContext.
This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.
In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself. I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.
llvm-svn: 96642
which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.
llvm-svn: 96396
comparing their types under the assumption that they are equivalent,
rather than importing the types and then checking for compatibility. A
few minor tweaks here:
- Teach structural matching to handle compatibility between
function types with prototypes and those without prototypes.
- Teach structural matching that an incomplete record decl is the
same as any other record decl with the same name.
- Keep track of pairs of declarations that we have already checked
(but failed to find as structurally matching), so we don't emit
diagnostics repeatedly.
- When importing a typedef of an anonymous tag, be sure to link the
imported tag type to its typedef.
With these changes, we survive a repeated import of <stdlib.h> and
<stdio.h>. Alas, the ASTNodeImporter is getting a little grotty.
llvm-svn: 96298
two types in different AST contexts are equivalent. Rather than
transforming the type from one context into the other context, we
perform a deep structural comparison of the types. This change
addresses a serious problem with recursive data types like
struct ListNode {
int value;
struct ListNode *Next;
} xList;
llvm-svn: 96278
those declared in it. This is to allow duplicate
property diagnostics for properties declared in class extensions
multiple times (radar 7629420) and for future use.
llvm-svn: 96276
incompatibility and show where the structural differences are. For
example:
struct1.c:36:8: warning: type 'struct S7' has incompatible definitions
in different translation units
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
struct S7 { int i : 8; unsigned j : 16; } x7;
^
There are a few changes to make this work:
- ASTImporter now has only a single Diagnostic object, not multiple
diagnostic objects. Otherwise, having a warning/error printed via
one Diagnostic and its note printed on the other Diagnostic could
cause the note to be suppressed.
- Implemented import functionality for IntegerLiteral (along with
general support for statements and expressions)
llvm-svn: 95900
array associated with NonNullAttr. This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.
Fixes: <rdar://problem/7637150>
llvm-svn: 95863
storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.
Fixes: <rdar://problem/7634755>
llvm-svn: 95861
array allocated using the allocator in ASTContext. This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).
Fixes: <rdar://problem/7636765>
llvm-svn: 95853
attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.
llvm-svn: 95820
merged with variables of constant array types. Also, make sure that we
call DiagnosticClient's BeginSourceFile/EndSourceFile, so that it has
a LangOptions to work with.
llvm-svn: 95782
into another AST, including their include history. Here's an example
error that involves a conflict merging a variable with different types
in two translation units (diagnosed in the third AST context into
which everything is merged).
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var2.c:3:5:
error: external variable 'x2' declared with incompatible types in
different translation units ('int' vs. 'double')
int x2;
^
In file included from
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.c:3:
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.h:1:8:
note: declared here with type 'double'
double x2;
^
Although we maintain include history, we do not maintain macro
instantiation history across a merge. Instead, we map down to the
spelling location (for now!).
llvm-svn: 95732
attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.
llvm-svn: 95571
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
llvm-svn: 95436
one context and import them into another context, merging them
according to language-specific rules. This is a skeleton. It doesn't
work, it isn't testable, but I want it in version control.
llvm-svn: 95395
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
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
void f(int a = 10) {
return a;
}
would always return 10, regardless of the passed in argument.
This fixes another 600 test failures. We're now down to only 137 failures!
llvm-svn: 95262
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
llvm-svn: 95189
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
llvm-svn: 94952
requires a temporary. Previously, we were building an initialization
sequence that bound to the bit-field as if it were a real lvalue. Note
that we previously (and still) diagnose binding of non-const
references to bit-fields, as we should.
There's no real way to test that this code is correct, since reference
binding does not *currently* have any representation in the AST. This
fix should make it easier for that to happen, so I've verified this
fix with...
Added InitializationSequence::dump(), to print an initialization
sequence for debugging purposes.
llvm-svn: 94826
region of interest (if provided). Implement clang_getCursor() in terms
of this traversal rather than using the Index library; the unified
cursor visitor is more complete, and will be The Way Forward.
Minor other tweaks needed to make this work:
- Extend Preprocessor::getLocForEndOfToken() to accept an offset
from the end, making it easy to move to the last character in the
token (rather than just past the end of the token).
- In Lexer::MeasureTokenLength(), the length of whitespace is zero.
llvm-svn: 94200
translation unit. This is temporary for function and block parameters;
template parameters can just stay this way, since Templates aren't
DeclContexts. This gives us the nice property that everything created
in a record DC should have access in C++.
llvm-svn: 94122
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
to merge the local instantiation scope with the outer local
instantiation scope, so that we can instantiate declarations from the
function owning the local class. Fixes an assert while instantiating
Boost.MPL's BOOST_MPL_ASSERT_MSG.
llvm-svn: 93651
previously only had a single location (the @ in @interface); now we
know where the @ is (for the start of the declaration), where the
class name is (that's the normal "location" now for diagnostics), and
where the category name is. Also, eliminated the redundant "end"
location, since ObjCContainerDecl already has better @end information.
The only XFAIL'd test is temporary; will un-XFAIL-it once I've taught
CIndex how to use the new locations.
llvm-svn: 93639
Objective-C classes, protocol definitions, forward protocol
declarations, and categories. This information isn't actually used
yet; that's coming next.
llvm-svn: 93636
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Find the
initializer anyway. Fixes PR6045.
llvm-svn: 93514
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
llvm-svn: 93433
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
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
llvm-svn: 93162
"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
try to evaluate an expression as a constant boolean condition. This has
the same intended semantics as used in folding conditional operators.
llvm-svn: 92805
- All classes can have a key function; templates don't change that.
non-template classes when computing the key function.
- We always mark all of the virtual member functions of class
template instantiations.
- The vtable for an instantiation of a class template has weak
linkage.
We could probably use available_externally linkage for vtables of
classes instantiated by explicit instantiation declarations (extern
templates), but GCC doesn't do this and I'm not 100% that the ABI
permits it.
llvm-svn: 92753
caught several cases where we were not doing the right thing. I'm
not completely sure all cases are being handled correctly, but this should
be an improvement.
llvm-svn: 92281
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
variable initializer and the other expressions in an IfStmt.
This change required adding a 'DoDestroy()' method for IfStmt that did
not include destroying the initializer (since that is owned by the
VarDecl).
llvm-svn: 92089
Anders Carlsson