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
derived-to-base cast that also casts away constness (one of the cases
for static_cast followed by const_cast) would be treated as a bit-cast
rather than a derived-to-base class, causing miscompiles and
heartburn.
Fixes <rdar://problem/8913298>.
llvm-svn: 124340
overload a function without a ref-qualifier (C++0x
[over.load]p2). This, apparently, completes the implementation of
rvalue references for *this.
llvm-svn: 124321
reference binding is for the implicit object parameter of a member
function with a ref-qualifier. My previous comment, that we didn't
need to track this explicitly, was wrong: we do in fact get
rvalue-references-prefer-rvalues overloading with ref-qualifiers.
llvm-svn: 124313
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
- Don't publicize a C++0x feature through __has_feature if we aren't
in C++0x mode (even if the feature is available only with a
warning).
- "auto" is not implemented well enough for its __has_feature to be
turned on.
- Fix the test of C++0x __has_feature to actually test what we're
trying to test. Searching for the substring "foo" when our options
are "foo" and "no_foo" doesn't work :)
llvm-svn: 124291
- 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
for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer
the binding of an lvalue reference to a function lvalue over the
binding of an rvalue reference. This change resolves the ambiguity
with std::forward and lvalue references to function types in a way
that seems consistent with the original rvalue references proposal.
My proposed wording for this change is shown in
isBetterReferenceBindingKind(); we'll try to get this change adopted
in the C++0x working paper as well.
llvm-svn: 124236
authors to write
class __attribute__((forbid_temporaries)) Name { ... };
when they want to force users to name all variables of the type. This protects
people from doing things like creating a scoped_lock that only lives for a
single statement instead of an entire scope.
The warning produced by this attribute can be disabled by
-Wno-forbid-temporaries.
llvm-svn: 124217
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
and turn on __has_feature(cxx_rvalue_references). The core rvalue
references proposal seems to be fully implemented now, pending lots
more testing.
llvm-svn: 124169
We translate property accesses to obj-c messages by simulating "loads" or "stores" to properties
using a pseudo-location SVal kind (ObjCPropRef).
Checkers can now reason about obj-c messages for both explicit message expressions and implicit
messages due to property accesses.
llvm-svn: 124161
messages that are sent for handling properties in dot syntax.
Replace all direct uses of ObjCMessageExpr in the checkers and checker interface with ObjCMessage.
llvm-svn: 124159
error: no super class declared in @interface for 'XXX'
to be:
error: 'X' cannot use 'super' because it is a root class
The latter explains what the user actually did wrong.
Fixes: <rdar://problem/8904409>
llvm-svn: 124074
to issue the warning at an uninitialized variable's
declaration, but to issue notes at possible
uninitialized uses (which could be multiple).
llvm-svn: 123994
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
NRVO candidate for a return statement, to
Sema::getCopyElisionCandidate(), and teach it enough to also determine
the NRVO candidate for a throw expression. We still don't use the
latter information, however.
Along the way, implement core issue 1148, which eliminates copy
elision from catch parameters and clarifies that copy elision cannot
occur from function parameters (which we already implemented).
llvm-svn: 123982
Inheritable attributes on declarations may be inherited by any later
redeclaration at merge time. By contrast, a non-inheritable attribute
will not be inherited by later redeclarations. Non-inheritable
attributes may be semantically analysed early, allowing them to
influence the redeclaration/overloading process.
Before this change, the "overloadable" attribute received special
handling to be treated as non-inheritable, while all other attributes
were treated as inheritable. This patch generalises the concept,
while removing a FIXME. Some CUDA location attributes are also marked
as non-inheritable in order to support special overloading semantics
(to be introduced in a later patch).
The patch introduces a new Attr subclass, InheritableAttr, from
which all inheritable attributes derive. Non-inheritable attributes
simply derive from Attr.
N.B. I did not review every attribute to determine whether it should
be marked non-inheritable. This can be done later on an incremental
basis, as this change does not affect default functionality.
llvm-svn: 123959
Turn on the __has_feature switch for variadic templates, document
their completion, and put the ExtWarn into the c++0x-extensions
warning group.
llvm-svn: 123854
ExtWarn. We want variadic templates to be usable in libc++/libstdc++
headers even when we're in C++98/03 mode, since it's the only clean
way to implement TR1 <functional>.
llvm-svn: 123852
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
there's a respectable point of instantiation. Also, make sure we do
this operation even when instantiating a dependently-typed variable.
llvm-svn: 123818
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
For example:
class A{
public:
A& operator=(const A& that) {
if (this != &that) {
this->A::~A();
this->A::A(that); // <=== explicit constructor call.
}
return *this;
}
};
More work will be needed to support an explicit call to a template constructor.
llvm-svn: 123735
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
another pack expansion type. This can happen when rebuilding types in
the current instantiation.
Fixes <rdar://problem/8848837> (Clang crashing on libc++ <functional>).
llvm-svn: 123316
the prefix should be ignored.
E.g. if ignorePrefix is true, "_init" and "init" selectors will both be result in InitRule, but if
ignorePrefix is false, only "init" will return InitRule.
llvm-svn: 123262
number of explicit call arguments. This actually fixes an erroneous
test for [temp.deduct.partial]p11, where we were considering
parameters corresponding to arguments beyond those that were
explicitly provided.
llvm-svn: 123244
parameters it expanded to, map exactly the number of function
parameters that were expanded rather than just running to the end of
the instantiated parameter list. This finishes the implementation of
the last sentence of C++0x [temp.deduct.call]p1.
llvm-svn: 123213
expression kinds. This is (indirectly) a test verifying that the
recursive AST visitor is visiting the children of these expression
nodes.
llvm-svn: 123198
allows an argument pack determines via explicit specification of
function template arguments to be extended by further, deduced
arguments. For example:
template<class ... Types> void f(Types ... values);
void g() {
f<int*, float*>(0, 0, 0); // Types is deduced to the sequence int*, float*, int
}
There are a number of FIXMEs in here that indicate places where we
need to implement + test retained expansions, plus a number of other
places in deduction where we need to correctly cope with the
explicitly-specified arguments when deducing an argument
pack. Furthermore, it appears that the RecursiveASTVisitor needs to be
auditied; it's missing some traversals (especially w.r.t. template
arguments) that cause it not to find unexpanded parameter packs when
it should.
The good news, however, is that the tr1::tuple implementation now
works fully, and the tr1::bind example (both from N2080) is actually
working now.
llvm-svn: 123163
TreeTransform version of TransformExprs() rather than explicit loop,
so that we expand pack expansions properly. Test cast coming soon...
llvm-svn: 123014
Fix an unexpected hickup caused by exceeding size of
generated table (and a misleading comment). Improve
on help message for -fapple-kext.
llvm-svn: 123003
parameters into parameter types, so that substitution of
explicitly-specified function template arguments uses the same
path. This enables the use of explicitly-specified function template
arguments with variadic templates.
llvm-svn: 122986
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
Fix the width and align of bool type on Darwin to be 32bits
while keeping it 8 everywhere else.
Change the definition of va_list to default to SV4 ABI one
and let darwin subtarget override this.
Both changes submitted by Nathan Whitehorn and reviewed
by Rafael Espindola.
llvm-svn: 122956
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
1) Declaration of function parameter packs
2) Instantiation of function parameter packs within function types.
3) Template argument deduction of function parameter packs when
matching two function types.
We're missing all of the important template-instantiation logic for
function template definitions, along with template argument deduction
from the argument list of a function call, so don't even think of
trying to use these for real yet.
llvm-svn: 122926
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
specializations. We weren't dealing with any of the cases where the
type of the non-type template argument differs from the type of the
corresponding template parameter in the primary template. We would
think that the template parameter in the partial specialization was
not deducible (and warn about it, incorrectly), then fail to convert a
deduced parameter to the type of the template parameter in the partial
specialization (which may involve truncation, among other
things). Fixes PR8905.
llvm-svn: 122851
int x = 42;
x = x; // Warns here.
The warning avoids macro expansions, templates, user-defined assignment
operators, and volatile types, so false positives are expected to be low.
The common (mis-)use of this code pattern is to silence unused variable
warnings, but a more idiomatic way of doing that is '(void)x;'.
A follow-up to this will add a note and fix-it hint suggesting this
replacement in cases where the StmtExpr consists precisely of the self
assignment.
llvm-svn: 122804
declaration name of the array when present. This ensures that
a poor-man's C++03 static_assert will include the user error message
often embedded in the name.
Update all the tests to reflect the new wording, and add a test for the
name behavior.
llvm-svn: 122802
When we are in code-completion mode, skip parsing of all function bodies except the one where the
code-completion point resides.
For big .cpp files like 'SemaExpr.cpp' the improvement makes a huge difference, in some cases cutting down
code-completion time -62% !
We don't get diagnostics for the bodies though, so modify the code-completion tests that check for errors.
See rdar://8814203.
llvm-svn: 122765
(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
don't have access to (e.g., fprintf, which needs the library type
FILE), fail with a warning and forget about the builtin
entirely. Previously, we would actually provide an error, which breaks
autoconf's super-lame checks for fprintf, longjmp, etc. Fixes PR8316.
llvm-svn: 122744
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
SimpleSValBuilder. This clears up some
false positives emitted by ArrayBoundCheckerV2
due to the lack of support for pointer arithmetic.
llvm-svn: 122546
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
parameter packs (C++0x [dcl.fct]p13), including disambiguation between
unnamed function parameter packs and varargs (C++0x [dcl.fct]p14) for
cases like
void f(T...)
where T may or may not contain unexpanded parameter packs.
llvm-svn: 122520
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
layout. :)
Rename the 'EntoSA' directories to 'StaticAnalyzer'.
Internally we will still use the 'ento' namespace
for the analyzer engine (unless there are further
sabre rattlings...).
llvm-svn: 122514
specialization's template arguments against the primary template's
template arguments using the obvious, correct method of checking the
injected-class-name type (C++ [temp.class.spec]p9b3). The previous
incarnation of this comparison attempted to use its own formulation of
the injected-class-name, which is redudant and, with the introduction
of variadic templates, became wrong (again).
llvm-svn: 122508
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
single routine. Extend that routine to handle consistency
checking for template argument packs, so that we can compare the
deduced packs for template parameter packs across different pack
expansions.
llvm-svn: 122452
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
deduction. Unify all of the looping over template arguments for
deduction purposes into a single place, where argument pack expansion
occurs; this is also the hook for deducing from pack expansions, which
itself is not yet implemented.
For now, at least we can handle a basic "count" metafunction written
with variadics. See the new test for the formulation that works.
llvm-svn: 122418
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
inconsistent with the type that the builtin *should* have, forget
about the builtin altogether: we don't want subsequence analyses,
CodeGen, etc., to think that we have a proper builtin function.
C is protected from errors here because it allows one to use a
library builtin without having a declaration, and detects inconsistent
(re-)declarations of builtins during declaration merging. C++ was
unprotected, and therefore would crash.
Fixes PR8839.
llvm-svn: 122351
classes, categories, protocols, and class extensions, where the
methods and properties of these entities would be inserted into the
DeclContext in an ordering that doesn't necessarily reflect source
order. The culprits were Sema::ActOnMethodDeclaration(), which did not
perform the insertion of the just-created method declaration into
the DeclContext for these Objective-C entities, and
Sema::ActOnAtEnd(), which inserted all method declarations at the
*end* of the DeclContext.
With this fix in hand, clean up the code-completion actions for
property setters/getters that worked around this brokenness in the AST.
Fixes <rdar://problem/8062781>, where this problem manifested as poor
token-annotation information, but this would have struck again in many
other places.
llvm-svn: 122347
clang_getCursorLexicalParent() to cope with class and function
templates, along with the parent of the translation unit. Fixes PR8761
and PR8766.
llvm-svn: 122324
unknown type and there is a possibility that
at runtime method is resolved to a deprecated or
unavailable method. Addreses // rdar://8769853
llvm-svn: 122294
shouldWalkTypesOfTypeLocs() that determines whether it should walk the
Types within TypeLocs. This walk is redundant, but perhaps required
for some clients. Disabling this redundant walk in the unexpanded
parameter pack finder produces better results, because we get
parameter packs with source location info *unless* such source
location information isn't available.
llvm-svn: 122287
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
to libAnalysis. Similar to Format (format string checking),
CocoaConventions has the
potential to serve clients other than the
static analyzer.
llvm-svn: 122040
implicit lvalue-to-rvalue casts that John McCall
recently introduced. This causes a whole bunch
of logic in the analyzer for handling lvalues
to vanish. It does, however, raise a few issues
in the analyzer w.r.t to modeling various constructs
(e.g., field accesses to compound literals).
The .c/.m analysis test cases that fail are
due to a missing lvalue-to-rvalue cast that
will get introduced into the AST. The .cpp
failures were more than I could investigate in
one go, and the patch was already getting huge.
I have XFAILED some of these tests, and they
should obviously be further investigated.
Some highlights of this patch include:
- CFG no longer requires an lvalue bit for
CFGElements
- StackFrameContext doesn't need an 'asLValue'
flag
- The "VisitLValue" path from GRExprEngine has
been eliminated.
Besides the test case failures (XFAILed), there
are surely other bugs that are fallout from
this change.
llvm-svn: 121960
Also tweak the VCVT_F32_F16 entry in arm_neon.td to be more consistent with
the other floating-point conversion builtins. Radar 8068427.
llvm-svn: 121916
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
parameter packs within a statement, type, etc. Use this visitor to
provide improved diagnostics for the presence of unexpanded parameter
packs in a full expression, base type, declaration type, etc., by
highlighting the unexpanded parameter packs and providing their names,
e.g.,
test/CXX/temp/temp.decls/temp.variadic/p5.cpp:28:85: error: declaration type
contains unexpanded parameter packs 'VeryInnerTypes',
'OuterTypes', ...
...VeryInnerTypes, OuterTypes>, pair<InnerTypes, OuterTypes> > types;
~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ ^
llvm-svn: 121883
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
within the class. Teach IR gen to look for function definitions in record
lexical contexts when deciding whether to emit a function whose address
was taken. Fixes PR8789.
llvm-svn: 121833
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
would return true if the initializer pointer union had *any* non-null
pointer in it, even if the pointer wasn't one that would actually be
returned via getInit(). This makes it more accurately model the logic of
'getInit() != NULL'.
This still isn't completely satisfying. From a principled stance,
I suspect we should make hasInit() and getInit() *always* return false
and NULL (resp.) for ParmVarDecl. We shouldn't at the API level treat
initializers and default arguments as the same thing.
llvm-svn: 121692
QualType::getTypePtr(). It turns out that
cast_or_null/dyn_cast_or_null don't actually use simplify_type, so
they're guaranteed to operator on non-NULL QualType or CanQualType
objects.
Good for a 0.6% win on 403.gcc's combine.c with -emit-llvm.
llvm-svn: 121495
common base for ExtQuals and Type that stores the underlying type
pointer. This results in a 2% performance win for -emit-llvm on a
typical C file, with 1% memory growth in the AST.
Note that there is an API change in this optimization:
QualType::getTypePtr() can no longer be invoked on a NULL
QualType. If the QualType might be NULL, use
QualType::getTypePtrOrNull(). I've audited all uses of getTypePtr() in
the code base and changed the appropriate uses over to
getTypePtrOrNull().
A future optimization opportunity would be to distinguish between
cast/dyn_cast and cast_or_null/dyn_cast_or_null; for the former, we
could use getTypePtr() rather than getTypePtrOrNull(), to take another
branch out of the cast/dyn_cast implementation.
llvm-svn: 121489
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
The sensible thing would be to have these intrinsics take all quad-register
vector operands, but that's not what ARM did. They made the last vector
operand always be a double-register type. Since the lane number
must be a constant, the user can know which half of a quad-register contains
that lane, extract the high or low half of the vector, and adjust the lane
number accordingly. The only advantage I can see for this is that it works
better when you want to multiply a quad-register value by a lane from a
double-register value, but I wouldn't have expected that to be the common
case. Oh well -- at this point we just need to follow the spec.
llvm-svn: 121397
"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
declaration that is a value in ill-formed code. Instead of crashing,
treat this as a dependent typename specifier and suggest that the
using add "typename" into the using declaration. Fixes <rdar://problem/8740998>.
llvm-svn: 121322
John McCall