lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory
optimization should be revisited later, when we have time to look at
the generated code.
llvm-svn: 126033
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
llvm-svn: 126016
that was ignored in a few places (most notably, code
completion). Introduce Selector::getNameForSlot() for the common case
where we only care about the name. Audit all uses of
getIdentifierInfoForSlot(), switching many over to getNameForSlot(),
fixing a few crashers.
Fixed <rdar://problem/8939352>, a code-completion crasher.
llvm-svn: 125977
bugs from other clients that don't expect to see a LabelDecl in a DeclStmt,
but if so they should be easy to fix.
This implements most of PR3429 and rdar://8287027
llvm-svn: 125817
making them be template instantiated in a more normal way and
make them handle attributes like other decls.
This fixes the used/unused label handling stuff, making it use
the same infrastructure as other decls.
llvm-svn: 125771
reducing the size of all declarations by one pointer. For a 64-bit
Clang parsing Cocoa.h, this saves ~630k of memory (about 3.5% of
ASTContext's memory usage for this header).
llvm-svn: 125756
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
llvm-svn: 125733
parameter type to see what's behind it, so that we don't end up
printing silly things like "float const *" when "const float *" would
make more sense. Also, replace the pile of "isa" tests with a simple
switch enumerating all of the cases, making a few more obvious cases
use prefix qualifiers.
llvm-svn: 125729
is unqualified but its initialized is qualified.
This is for c only and fixes the imm. problem.
c++ is more involved and is wip.
// rdar://8979379
llvm-svn: 125386
linkage into Decl.cpp. Disable this logic for extern "C" functions, because
the operative rule there is weaker. Fixes rdar://problem/8898466
llvm-svn: 125268
there were only three virtual methods of any significance.
The primary way to grab child iterators now is with
Stmt::child_range children();
Stmt::const_child_range children() const;
where a child_range is just a std::pair of iterators suitable for
being llvm::tie'd to some locals. I've left the old child_begin()
and child_end() accessors in place, but it's probably a substantial
penalty to grab the iterators individually now, since the
switch-based dispatch is kindof inherently slower than vtable
dispatch. Grabbing them together is probably a slight win over the
status quo, although of course we could've achieved that with vtables, too.
I also reclassified SwitchCase (correctly) as an abstract Stmt
class, which (as the first such class that wasn't an Expr subclass)
required some fiddling in a few places.
There are somewhat gross metaprogramming hooks in place to ensure
that new statements/expressions continue to implement
getSourceRange() and children(). I had to work around a recent clang
bug; dgregor actually fixed it already, but I didn't want to
introduce a selfhosting dependency on ToT.
llvm-svn: 125183
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
might be queried in places where we absolutely require a valid
location (e.g., for template instantiation). Fixes some major
brokenness in the use of __is_convertible_to.
llvm-svn: 124465
semantics after the C++0x is_convertible type trait. This
implementation is not 100% complete, because it allows access errors
to be hard errors (rather than just evaluating false).
Original patch by Steven Watanabe!
llvm-svn: 124425
deallocation function has a two-argument form. Store the result of this
check in new[] and delete[] nodes.
Fixes rdar://problem/8913519
llvm-svn: 124373
using rules that I just made up this morning. This encoding has now
been proposed to the Itanium C++ ABI group for inclusion, but of
course it's still possible that the mangling will change.
llvm-svn: 124296
- Add ref-qualifiers to the type system; they are part of the
canonical type. Print & profile ref-qualifiers
- Translate the ref-qualifier from the Declarator chunk for
functions to the function type.
- Diagnose mis-uses of ref-qualifiers w.r.t. static member
functions, free functions, constructors, destructors, etc.
- Add serialization and deserialization of ref-qualifiers.
llvm-svn: 124281
generate meaningful [*] template argument location information.
[*] Well, as meaningful as possible, given that this entire code path
is a hack for when we've lost type-source information.
llvm-svn: 124211
when returning an NRVO candidate expression. For example, this
properly picks the move constructor when dealing with code such as
MoveOnlyType f() { MoveOnlyType mot; return mot; }
The previously-XFAIL'd rvalue-references test case now works, and has
been moved into the appropriate paragraph-specific test case.
llvm-svn: 123992
involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.
llvm-svn: 123913
together. In particular:
- Handle the use of captured parameter pack names within blocks
(BlockDeclRefExpr understands parameter packs now)
- Handle the declaration and expansion of parameter packs within a block's
parameter list, e.g., ^(Args ...args) { ... })
- Handle instantiation of blocks where the return type was not
explicitly specified. (unrelated, but necessary for my tests).
Together, these fixes should make blocks and variadic templates work
reasonably well together. Note that BlockDeclRefExpr is still broken
w.r.t. its computation of type and value dependence, which will still
cause problems for blocks in templates.
llvm-svn: 123849
a pack expansion, e.g., the parameter pack Values in:
template<typename ...Types>
struct Outer {
template<Types ...Values>
struct Inner;
};
This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.
llvm-svn: 123845
outermost array types and not on the element type. Move the CanonicalType
member from Type to ExtQualsTypeCommonBase; the canonical type on an ExtQuals
node includes the qualifiers on the ExtQuals. Assorted optimizations enabled
by this change.
getQualifiers(), hasQualifiers(), etc. should all now implicitly look through
array types.
llvm-svn: 123817
::getCVRQualifiers() now look through array types, like all the other
standard queries. Also, make a 'split' variant of getUnqualifiedType().
llvm-svn: 123751
template template parameter pack that cannot be fully expanded because
its enclosing pack expansion could not be expanded. This form of
TemplateName plays the same role as SubstTemplateTypeParmPackType and
SubstNonTypeTemplateParmPackExpr do for template type parameter packs
and non-type template parameter packs, respectively.
We should now handle these multi-level pack expansion substitutions
anywhere. The largest remaining gap in our variadic-templates support
is that we cannot cope with non-type template parameter packs whose
type is a pack expansion.
llvm-svn: 123521
that captures the substitution of a non-type template argument pack
for a non-type template parameter pack within a pack expansion that
cannot be fully expanded. This follows the approach taken by
SubstTemplateTypeParmPackType.
llvm-svn: 123506
expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).
Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.
The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.
llvm-svn: 123448
involve template parameter packs at multiple template levels that
occur within the signatures members of class templates (and partial
specializations thereof). This is a work-in-progress that is deficient
in several ways, notably:
- It only works for template type parameter packs, but we need to
also support non-type template parameter packs and template template
parameter packs.
- It doesn't keep track of the lengths of the substituted argument
packs in the expansion, so it can't properly diagnose length
mismatches.
However, this is a concrete step in the right direction.
llvm-svn: 123425
process, perform a number of refactorings:
- Move MiscNameMangler member functions to MangleContext
- Remove GlobalDecl dependency from MangleContext
- Make MangleContext abstract and move Itanium/Microsoft functionality
to their own classes/files
- Implement ASTContext::createMangleContext and have CodeGen use it
No (intended) functionality change.
llvm-svn: 123386
sentence of [temp.deduct.call]p1, both of which concern the
non-deducibility of parameter packs not at the end of a
parameter-type-list. The latter isn't fully implemented yet; see the
new FIXME.
llvm-svn: 123210
template whose last parameter is a parameter pack. This allows us to
form a call to, e.g.,
template<typename ...Args1, typename ...Args2>
void f(std::pair<Args1, Args2> ...pairs);
given zero or more instances of "pair".
llvm-svn: 122973
The initial TreeTransform is a cop-out, but it's more-or-less equivalent
to what we were doing before, or rather what we're doing now and might
eventually stop doing in favor of using this type.
I am simultaneously intrigued by the possibilities of rebuilding a
dependent Attri
llvm-svn: 122942
initialize *all* of the bits to zero. Also, when the pattern of a
template argument pack expansion, make sure to set the ellipsis
location along all paths.
This should clear up the valgrind failure that popped up in Clang.
llvm-svn: 122931
parameter packs, along with ParmVarDecl::isParameterPack(), which
looks for function parameter packs. Use these routines to fix some
obvious FIXMEs.
llvm-svn: 122904
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
llvm-svn: 122896
for template template argument pack expansions. This allows fun such
as:
template<template<class> class ...> struct apply_impl { /*...*/ };
template<template<class> class ...Metafunctions> struct apply {
typedef typename apply_impl<Metafunctions...>::type type;
};
However, neither template argument deduction nor template
instantiation is implemented for template template argument packs, so
this functionality isn't useful yet.
I'll probably replace the encoding of template template
argument pack expansions in TemplateArgument so that it's harder to
accidentally forget about the expansion. However, this is a step in
the right general direction.
llvm-svn: 122890
the declaration-specifiers and on the declarator itself are moved
to the appropriate declarator chunk. This permits a greatly
simplified model for how to apply these attributes, as well as
allowing a much more efficient query for the GC attribute.
Now all qualifier queries follow the same basic strategy of
"local qualifiers, local qualifiers on the canonical type,
then look through arrays". This can be easily optimized by
changing the canonical qualified-array-type representation.
Do not process type attributes as decl attributes on declarations
with declarators.
When computing the type of a block, synthesize a prototype
function declarator chunk if the decl-spec type was not a
function. This simplifies the logic for building block signatures.
Change the logic which inserts an objc_read_weak on a block
literal to only fire if the block has a __weak __block variable,
rather than if the return type of the block is __weak qualified,
which is not actually a sensible thing to ask.
llvm-svn: 122871
(transforming each in turn) into calls into one central routine
(TransformExprs) that transforms a list of expressions. This
refactoring is preparatory work for pack expansions whose in an
expression-list.
No functionality change.
llvm-svn: 122761
template argument (described by an expression, of course). For
example:
template<int...> struct int_tuple { };
template<int ...Values>
struct square {
typedef int_tuple<(Values*Values)...> type;
};
It also lays the foundation for pack expansions in an initializer-list.
llvm-svn: 122751
The problem was that we were asserting the we never added an empty class
to the same offset twice. This is not true for unions, where two members, empty
or not, can have the some offset.
llvm-svn: 122633
16-bits in size. Implement this by splitting WChar into two enums, like we have
for char. This fixes a miscompmilation of XULRunner, PR8856.
llvm-svn: 122558
extract the appropriate argument from the argument pack (based on the
current substitution index, of course). Simple instantiation of pack
expansions involving non-type template parameter packs now works.
llvm-svn: 122532
packs, e.g.,
template<typename T, unsigned ...Dims> struct multi_array;
along with semantic analysis support for finding unexpanded non-type
template parameter packs in types, expressions, and so on.
Template instantiation involving non-type template parameter packs
probably doesn't work yet. That'll come soon.
llvm-svn: 122527
template argument corresponding to a template parameter pack is an
argument pack of a pack expansion of that template parameter
pack. Implements C++0x [temp.dep.type]p2 (at least, as much of it as
we can).
llvm-svn: 122498
new gcc warning that complains on self-assignments and
self-initializations. Fix one bug found by the warning, in which one
clang::OverloadCandidate constructor failed to initialize its
FunctionTemplate member.
llvm-svn: 122459
pattern is a template argument, which involves repeatedly deducing
template arguments using the pattern of the pack expansion, then
bundling the resulting deductions into an argument pack.
We can now handle a variety of simple list-handling metaprograms using
variadic templates. See, e.g., the new "count" metaprogram.
llvm-svn: 122439
Previously designated anonymous fields were found via name lookup. This redesign uses the fact that an IndirectFieldDecl declaration will always follow an anonymous implicit field to remove the special case of name lookup.
llvm-svn: 122387
whose patterns are template arguments. We can now instantiate, e.g.,
typedef tuple<pair<OuterTypes, InnerTypes>...> type;
where OuterTypes and InnerTypes are template type parameter packs.
There is a horrible inefficiency in
TemplateArgumentLoc::getPackExpansionPattern(), where we need to
create copies of TypeLoc data because our interfaces traffic in
TypeSourceInfo pointers where they should traffic in TypeLocs
instead. I've isolated in efficiency in this one routine; once we
refactor our interfaces to traffic in TypeLocs, we can eliminate it.
llvm-svn: 122278
area of printing template arguments. The functionality changes here
are limited to cases of variadic templates that aren't yet enabled.
llvm-svn: 122250
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
declarations. This is a work in progress, as I go through the C++
declaration grammar to identify where unexpanded parameter packs can
occur.
llvm-svn: 121912
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
class to be passed around. The line between argument and return types and
everything else is kindof vague, but I think it's justifiable.
llvm-svn: 121752
and TemplateArgument with an operation that determines whether there
are any unexpanded parameter packs within that construct. Use this
information to diagnose the appearance of the names of parameter packs
that have not been expanded (C++ [temp.variadic]p5). Since this
property is checked often (every declaration, ever expression
statement, etc.), we extend Type and Expr with a bit storing the
result of this computation, rather than walking the AST each time to
determine whether any unexpanded parameter packs occur.
This commit is deficient in several ways, which will be remedied with
future commits:
- Expr has a bit to store the presence of an unexpanded parameter
pack, but it is never set.
- The error messages don't point out where the unexpanded parameter
packs were named in the type/expression, but they should.
- We don't check for unexpanded parameter packs in all of the places
where we should.
- Testing is sparse, pending the resolution of the above three
issues.
llvm-svn: 121724
space better. Remove this reference. To make that work, change some APIs
(most importantly, getDesugaredType()) to take an ASTContext& if they
need to return a QualType. Simultaneously, diminish the need to return a
QualType by introducing some useful APIs on SplitQualType, which is
just a std::pair<const Type *, Qualifiers>.
llvm-svn: 121478
increasing the required type alignment from 8 to 16. This provides a
2.5% speedup for -fsyntax-only on a token-cached Cocoa.h, while only
increasing memory consumption in the ASTContext by 0.8%.
llvm-svn: 121474
visibility. Fixes PR8713.
I've disabled a test which was testing that you can #pragma pop visibility
to get out of a namespace's visibility attribute. We should probably just
diagnose that as an error unless it's instrumental to someone's system
headers.
llvm-svn: 121459
"inline", we weren't giving the definition weak linkage because the
"inline" bit wasn't propagated. This was a longstanding FIXME that,
somehow, hadn't triggered a bug in the wild. Fix this problem by
tracking whether any declaration was marked "inline", and clean up the
semantics of GNU's "extern inline" semantics calculation based on this
change.
Fixes <rdar://problem/8740363>.
llvm-svn: 121373
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121121
My previous attempt at solving the compile-time problem with many
redeclarations of the same entity cached both linkage and visibility,
while this patch only tackles linkage. There are several reasons for
this difference:
- Linkage is a language concept, and is evaluated many times during
semantic analysis and codegen, while visibility is only a
code-generation concept that is evaluated only once per (unique)
declaration. Hence, we *must* optimize linkage calculations but
don't need to optimize visibility computation.
- Once we know the linkage of a declaration, subsequent
redeclarations can't change that linkage. Hence, cache
invalidation is far simpler than for visibility, where a later
redeclaration can completely change the visibility.
- We have 3 spare bits in Decl to store the linkage cache, so the
cache doesn't increase the size of declarations. With the
visibility+linkage cache, NamedDecl got larger.
llvm-svn: 121023
and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.
An improved implementation is forthcoming.
llvm-svn: 121012
build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later. Fixes PR8739.
llvm-svn: 120990
struct X {
X() : au_i1(123) {}
union {
int au_i1;
float au_f1;
};
};
clang will now deal with au_i1 explicitly as an IndirectFieldDecl.
llvm-svn: 120900
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ. So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.
In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.
This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.
Ted Kremenek kindly contributed the analyzer workarounds in this patch.
llvm-svn: 120890
declarations.
The motivation for this patch is that linkage/visibility computations
are linear in the number of redeclarations of an entity, and we've run
into a case where a single translation unit has > 6500 redeclarations
of the same (unused!) external variable. Since each redeclaration
involves a linkage check, the resulting quadratic behavior makes Clang
slow to a crawl. With this change, a simple test with 512
redeclarations of a variable syntax-checks ~20x faster than
before.
That said, I hate this change, and will probably end up reverting it
in a few hours. Reasons to hate it:
- It makes NamedDecl larger, since we don't have enough free bits in
Decl to squeeze in the extra information about caching.
- There are way too many places where we need to invalidate this
cache, because the visibility of a declaration can change due to
redeclarations (!). Despite self-hosting and passing the testsuite,
I have no confidence that I've found all of places where this cache
needs to be invalidated.
llvm-svn: 120808
definition of an Objective-C class. Unlike with C/C++ classes, we
don't have a well-defined point in Sema where Objective-C classes are
checked for completeness, nor do we need to involve Sema when
completing a class. Therefore, we take the appropriate of having the
external AST source mark a particular Objective-C class as having an
external declaration; when using one of the accessors of an
Objective-C class that has an external declaration, we request that
the external AST source fill in the Objective-C class definition.
llvm-svn: 120627
of the ASTs. Only available in assertions builds. No stability guarantee.
This is intended solely as a debugging tool. I'm not sure if the goals
are sufficiently aligned with the XML printer to allow a common
implementation.
Currently just falls back on the StmtDumper to display statements,
which means it doesn't produce valid XML in those cases.
llvm-svn: 120088
- Default argument expressions pick up the value kind of the incoming
expression, not the value kind of the parameter it initializes.
- When building a template argument for substitution, A::x is an rvalue
if x is an instance method.
- Anonymous struct/union paths pick up value kind the same way that
normal member accesses do; extract out a common code path for this.
Enable the value-kind assertion, now that it passes self-host.
llvm-svn: 120055
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
llvm-svn: 120010
A new AST node is introduced:
def IndirectField : DDecl<Value>;
IndirectFields are injected into the anonymous's parent scope and chain back to
the original field. Name lookup for anonymous entities now result in an
IndirectFieldDecl instead of a FieldDecl.
There is no functionality change, the code generated should be the same.
llvm-svn: 119919
and use a better and more general approach, where NullStmt has a flag to indicate whether it was preceded by an empty macro.
Thanks to Abramo Bagnara for the hint!
llvm-svn: 119887
-Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class.
-DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units.
-The rest of the state in Diagnostic object is considered related and tied to one translation unit.
-Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a
SourceLocation instead of a FullSourceLoc.
-Reflect the changes to various interfaces.
llvm-svn: 119730
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
no longer depends on Preprocessor, so we can move it out of Sema into
a nice new StringLiteral::getLocationOfByte method that can be used by
any AST client.
llvm-svn: 119481
assignment to volatiles in C. This in effect reverts some of mjs's
work in and around r72572. Basically, the C++ standard is quite
clear, except that it lies about volatile behavior approximating
C's, whereas the C standard is almost actively misleading.
llvm-svn: 119344
in more situations. In particular, for code like
template<class T> void Fn() { T* x; delete x; }
getDestroyedType() will now return T rather than T*, as it would
before this change. On the other hand, for code like this:
template<class T> void Fn() { T x; delete x; }
getDestroyedType() will return an empty QualType(), since it doesn't
know what the actual destroyed type would be. Previously, it would
return T.
OKed by rjmccall
llvm-svn: 119334
This is needed for Neon types when it is most natural to define them in terms
of a typedef. For example, Neon poly8_t is a typedef for "signed char", and
we want to define polynomial vectors as vectors of that typedef. Without this
change, the result will be a generic GCC-style vector. I think this is safe
for other vector types as well, but I would appreciate a review of this.
llvm-svn: 119300
implicit conversions; the last batch was specific to promotions.
I think this is the full set we need. I do think dividing the cast
kinds into floating and integral is probably a good idea.
Annotate a *lot* more C casts with useful cast kinds.
llvm-svn: 119036
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.
llvm-svn: 118724
own subcategory, -Wconstant-conversion, which is on by default.
Tweak the constant folder to give better results in the invalid
case of a negative shift amount.
Implements rdar://problem/6792488
llvm-svn: 118636
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).
llvm-svn: 118598
constructor template will not be used to copy a class object to a
value of its own type. We were eliminating all constructor templates
whose specializations look like a copy constructor, which eliminated
important candidates. Fixes PR8182.
llvm-svn: 118418
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
or dependent specializations, rip apart the dependent name/dependent
specialization to recanonicalize its pieces, because
nested-name-specifiers store "dependent-type::identifier" differently
than types do. Fixes PR7419.
llvm-svn: 118211
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
llvm-svn: 118203
ensuring that they cover all of their child nodes. There's still a
clang_getCursor()-related issue with CXXFunctionalCastExprs with
CXXConstructExprs as children (see FIXME in the test case); I'll look
at that separately.
llvm-svn: 118132
with their own explicit visibility attributes. Basically we only want to
apply a single visibility attribute from any particular ancestry.
llvm-svn: 117998
independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations. Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.
More of rdar://problem/8613093
llvm-svn: 117781
whether it's a declaration or not, then ignores that information for
declarations unless it was explicitly given. It's not totally clear
how that should be mapped into a sane system, but make an effort.
llvm-svn: 117780
for namespace-scope variable declarations.
Apply visibility in IR gen to variables that are merely declared
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
llvm-svn: 117729
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
llvm-svn: 117644
in the scope checker. With that done, turn an indirect goto into a
protected scope into a hard error; otherwise IR generation has to start
worrying about declarations not dominating their scopes, as exemplified
in PR8473.
If this really affects anyone, I can probably adjust this to only hard-error
on possible indirect gotos into VLA scopes rather than arbitrary scopes.
But we'll see how people cope with the aggressive change on the marginal
feature.
llvm-svn: 117539
There's probably still significant padding waste on x86-64 UNIXen, but
the difference in 32-bit compiles should be significant.
There are a lot of Expr nodes left that could lose a word this way.
llvm-svn: 117359
- tags with C linkage should ignore visibility=hidden
- functions and variables with explicit visibility attributes should
ignore the linkage of their types
Either of these should be sufficient to fix PR8457.
Also, FileCheck-ize a test case.
llvm-svn: 117351
getCanonicalType() to make sure that the type we got back is actually
canonical. This is the case for most types, which always build a
canonical type when given canonical components. However, some types that
involve expressions in their canonicalization (e.g., array types with
dependent sizes) don't always build canonical types from canonical
components, because there is no such thing as a "canonical"
expression. Therefore, we do this extra mapping to ensure that the
canonical types we store are actually canonical.
llvm-svn: 117344
This adds them where missing, and traces them through PCH. We fix at least one
bug in the extents found by the Index library, and make a lot of refactoring
tools which care about the exact formulation of a constructor call easier to
write. Also some minor cleanups to more consistently follow the friend pattern
instead of the setter pattern when rebuilding a serialized AST.
Patch originally by Samuel Benzaquen.
llvm-svn: 117254
In that case a chained PCH will record the updates to the DefinitionData pointer of forward references.
If a forward reference mutated into a definition re-write it into the chained PCH, this is too big of a change.
llvm-svn: 117239
its initial creation/deserialization and store the changes in a chained PCH.
The idea is that the AST entities call methods on the ASTMutationListener to give notifications
of changes; the PCHWriter implements the ASTMutationListener interface and stores the incremental changes
of the updated entity. WIP
llvm-svn: 117235
more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
llvm-svn: 117147
redeclarations of main appropriately rather than allowing it to be
overloaded. Also, disallowing declaring main as a template.
Fixes GCC DejaGNU g++.old-deja/g++.other/main1.C.
llvm-svn: 117029
Here's example code:
---
template<class T> class MyClass {
struct S { };
S* NewS() { return new S; }
void DeleteS() { delete NewS(); }
};
---
CXXDeleteExpr::getDestroyedType() on the 'delete NewS()' expression
would crash before this change. Now it returns a dependent type
object. Solution suggested by dgregor.
llvm-svn: 116891
instead of deserializing the complete declaration context of the record.
Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration
that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods.
Fix this by allow deserialization of just the fields when we want to iterate over them.
Progress for rdar://7260160.
llvm-svn: 116507
unnamed or local types within that type. This bit is cached along with
the linkage of a type, so that it can be recomputed (e.g., when we see
that a typedef has given a name to an anonymous declaration).
Use this bit when checking C++03 [temp.arg.type]p2, so that we don't
walk template argument types repeatedly.
llvm-svn: 116413
unless it's a non-packed field, in which case it can only increase the
alignment. [[align]] effectively works the same way for well-formed code
(because it's ill-formed for [[align]] to decrease alignment ever).
Fixes rdar://problem/8335865
llvm-svn: 116070
one results in an obscure error from the backend that doesn't make
sense. Capture this information in the .def files for builtins with
a new "I" modifier letter indicating the an argument needs to be an ICE.
Nothing uses this yet, but sema will eventually enforce this (eliminating
some special cases from semachecking.cpp) and codegen will use this to
force an ICE value, preventing backend error messages.
llvm-svn: 115302
into CXXRecordDecl. The only part that we do not handle this way are
using declarations, since that would require extra name lookup that we
don't currently want to pay for. This fixes <rdar://problem/8459981>,
so that LLDB can build a CXXRecordDecl and magically get all of the
right bits set.
llvm-svn: 115026
completely into CXXRecordDecl, by adding a new completeDefinition()
function. This required a little reshuffling of the final-overrider
checking code, since the "abstract" calculation in the presence of
abstract base classes needs to occur in
CXXRecordDecl::completeDefinition() but we don't want to compute final
overriders more than one in the common case.
llvm-svn: 115007
in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>.
This reinstates r114924, with one crucial bug fix: we were ignoring
the implicit fields created by anonymous structs/unions when updating
the bits in CXXRecordDecl, which means that a class/struct containing
only an anonymous class/struct would be considered "empty". Hilarity
follows.
llvm-svn: 114980
Centralize the management of CXXRecordDecl::DefinitionData's Aggregate
and PlainOldData bits in CXXRecordDecl itself. Another milepost on the
road toward <rdar://problem/8459981>.
llvm-svn: 114977
one of them) was causing a series of failures:
http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-selfhost/builds/4518
svn merge -c -114929 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114929 into '.':
U include/clang/Sema/Sema.h
U include/clang/AST/DeclCXX.h
U lib/Sema/SemaDeclCXX.cpp
U lib/Sema/SemaTemplateInstantiateDecl.cpp
U lib/Sema/SemaDecl.cpp
U lib/Sema/SemaTemplateInstantiate.cpp
U lib/AST/DeclCXX.cpp
svn merge -c -114925 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114925 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/AST/DeclCXX.cpp
svn merge -c -114924 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114924 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/Sema/SemaDecl.cpp
G lib/AST/DeclCXX.cpp
U lib/AST/ASTContext.cpp
svn merge -c -114921 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114921 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/Sema/SemaDecl.cpp
G lib/AST/DeclCXX.cpp
llvm-svn: 114933
HasTrivialConstructor, HasTrivialCopyConstructor,
HasTrivialCopyAssignment, and HasTrivialDestructor bits in
CXXRecordDecl's methods. This completes all but the Abstract bit and
the set of conversion functions, both of which will require a bit of
extra work. The majority of <rdar://problem/8459981> is now
implemented (but not all of it).
llvm-svn: 114929
already be determined by isCopyAssignmentOperator(), and was set too
late in the process for all clients to see the appropriate
value. Cleanup only; no functionality change.
llvm-svn: 114916
DeclaredCopyConstructor bits in CXXRecordDecl's DefinitionData
structure. Rather than having Sema call addedConstructor or set the
bits directly at semi-random places, move all of the logic for
managing these bits into CXXRecordDecl itself and tie the
addedConstructor call into DeclContext::addDecl().
This makes it easier for AST-building clients to get the right bits
set in DefinitionData, and is one small part of <rdar://problem/8459981>.
llvm-svn: 114889
-Wpadded warns when undesired padding is introduced in a struct. (rdar://7469556)
-Wpacked warns if a struct is given the packed attribute, but the packed attribute has no effect
on the layout or the size of the struct. Such structs may be mis-aligned for little benefit.
The warnings are emitted at the point where layout is calculated, that is at RecordLayoutBuilder.
To avoid calculating the layouts of all structs regardless of whether they are needed or not,
I let the layouts be lazily constructed when needed. This has the disadvantage that the above warnings
will be emitted only when they are used for IR gen, and not e.g with -fsyntax-only:
$ cat t.c
struct S {
char c;
int i;
};
void f(struct S* s) {}
$ clang -fsyntax-only -Wpadded t.c
$ clang -c -Wpadded t.c -o t.o
t.c:3:7: warning: padding struct 'struct S' with 3 bytes to align 'i' [-Wpadded]
int i;
^
1 warning generated.
This is a good tradeoff between providing the warnings and not calculating layouts for all
structs in case the user has enabled a couple of rarely used warnings.
llvm-svn: 114544
slot. The easiest way to do that was to bundle up the information
we care about for aggregate slots into a new structure which demands
that its creators at least consider the question.
I could probably be convinced that the ObjC 'needs GC' bit should
be rolled into this structure.
Implement generalized copy elision. The main obstacle here is that
IR-generation must be much more careful about making sure that exactly
llvm-svn: 113962
"used", at the time that the default argument itself is used, also
mark destructors that will be called by this expression. This fixes a
regression that I introduced in r113700, which broke WebKit, and fixes
<rdar://problem/8427926>.
llvm-svn: 113883
that we're sure to keep it updated when new expression kinds
emerge. Also fixes a few little bugs in the classification of
expressions.
llvm-svn: 113864
follows objective's semantics and is not overload'able
with an assignment operator. Fixes a crash and a missing
diagnostics. Radar 8379892.
llvm-svn: 113555
Another beating by boost in this test case: http://llvm.org/PR8117
A function specialization wasn't properly initialized if it wasn't canonical.
I wish there was a nice little test case but this was boost.
llvm-svn: 113481
PCH got a severe beating by the boost-using test case reported here: http://llvm.org/PR8099
Fix issues like:
-When PCH reading, make sure Decl's getASTContext() doesn't get called since a Decl in the parent hierarchy may be initializing.
-In ASTDeclReader::VisitFunctionDecl VisitRedeclarable should be called before using FunctionDecl's isCanonicalDecl()
-In ASTDeclReader::VisitRedeclarableTemplateDecl CommonOrPrev must be initialized before anything else.
llvm-svn: 113391
Fixes PR8110, and thus PR8109, PR8097, and parts of PR8101, PR8105 and PR8107. Only a few traits have tests for incomplete arrays, since I'm not yet clear what the result for them should be; Howards wants to file a DR to change the standard.
llvm-svn: 113326
initializers, so the result of the evaluation doesn't leak through
inconsistently. Also, don't evaluate references to variables with
initializers with side-effects.
llvm-svn: 113128
suppressing USRs). Also, fix up the source location information for
using directives so that the declaration location refers to the
namespace name.
llvm-svn: 112693
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
ASTContext::DeclAttrs. Otherwise, iterators will go stale when the
DenseMap reallocates, which can cause crashes when, e.g., looping over
the attributes in a template to instantiate them and add the results
to the instantiation of that template.
llvm-svn: 112488
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
For large floats/integers, APFloat/APInt will allocate memory from the heap to represent these numbers.
Unfortunately, when we use a BumpPtrAllocator to allocate IntegerLiteral/FloatingLiteral nodes the memory associated with
the APFloat/APInt values will never get freed.
I introduce the class 'APNumericStorage' which uses ASTContext's allocator for memory allocation and is used internally by FloatingLiteral/IntegerLiteral.
Fixes rdar://7637185
llvm-svn: 112361
an '&' expression from the second caller of ActOnIdExpression.
Teach template argument deduction that an overloaded id-expression
doesn't give a valid type for deduction purposes to a non-static
member function unless the expression has the correct syntactic
form.
Teach ActOnIdExpression that it shouldn't try to create implicit
member expressions for '&function', because this isn't a
permitted form of use for member functions.
Teach CheckAddressOfOperand to diagnose these more carefully.
Some of these cases aren't reachable right now because earlier
diagnostics interrupt them.
llvm-svn: 112258
Ken Dyck