nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
llvm-svn: 126391
way it keeps track of namespaces. Previously, we would map from the
namespace alias to its underlying namespace when building a
nested-name-specifier, losing source information in the process.
llvm-svn: 126358
with another component in the nested-name-specifiers, updating its
representation (a NestedNameSpecifier) and source-location information
(currently a SourceRange) simultaneously. This is groundwork for
adding source-location information to nested-name-specifiers.
llvm-svn: 126346
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
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
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
- 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
during template instantiation. This code needs to eventually die, but
this little tweak fixes PR8629, where bad location information slipped
through to the location of a class template instantiation.
llvm-svn: 124199
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
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
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
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
and function templates that contain variadic templates. This involves
three small-ish changes:
(1) When transforming a pack expansion, if the transformed argument
still contains unexpanded parameter packs, build a pack
expansion. This can happen during the substitution that occurs into
class template partial specialiation template arguments during
partial ordering.
(2) When performing template argument deduction where the argument
is a pack expansion, match against the pattern of that pack
expansion.
(3) When performing template argument deduction against a non-pack
parameter, or a non-expansion template argument, deduction fails if
the argument itself is a pack expansion (C++0x
[temp.deduct.type]p22).
llvm-svn: 123279
pack expansions in template argument lists and function parameter
lists. The implementation of this paragraph should be complete
*except* for cases where we're substituting into one of the unexpanded
packs in a pack expansion; that's a general issue I haven't solved yet.
llvm-svn: 123188
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
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
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
TypeSourceInfo when transforming a function parameter. The callees of
this routine already assume that TypeSourceInfo will be present, and
we want to always be sure that it exists.
llvm-svn: 122927
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
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
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
lists, so that all such transformations go through a single,
iterator-based transformation function. This is the only place where
we need to implement the logic for transforming pack expansions whose
pattern is a template argument.
Unfortunately, the new cases this refactoring brings into the fold
can't be meaningfully tested yet. We need template argument deduction
to work well enough for variadic function templates first.
llvm-svn: 122289
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
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
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
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
parameters to the Transform*Type functions and instead call out
the specific cases where an object type and the unqualified lookup
results are important. Fixes an assert and failed compile on
a testcase from PR7248.
llvm-svn: 118887
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
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
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
arguments in either the placement or constructor arguments. This is
important if the default arguments refer to a declaration or create a
temporary.
llvm-svn: 115700
"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
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
TreeTransform, since we were getting an empty source range where we
shouldn't. Sadly, the test case is Boost.Proto, and isn't worth
reducing.
llvm-svn: 113446
instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.
We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.
We now compile Boost.Polygon properly.
llvm-svn: 112561
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
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.
llvm-svn: 106167
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.
llvm-svn: 106161
introduced by using decls are hidden even if their template parameter lists
or return types differ from the "overriding" declaration.
Propagate using shadow declarations around more effectively when looking up
template-ids. Reperform lookup for template-ids in member expressions so that
access control is properly set up.
Fix some number of latent bugs involving template-ids with totally invalid
base types. You can only actually get these with a scope specifier, since
otherwise the template-id won't parse as a template-id.
Fixes PR7384.
llvm-svn: 106093
case of an elaborated-type-specifier like 'typename A<T>::foo', and
DependentTemplateSpecializationType represents the case of an
elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc
representation of a DependentTST conveniently exactly matches that of an
ElaboratedType wrapping a TST.
Kill off the explicit rebuild methods for RebuildInCurrentInstantiation;
the standard implementations work fine because the nested name specifier
is computable in the newly-entered context.
llvm-svn: 105801
or block-pointer type by removing the qualifiers parameter. Introduce a
method to perform semantic checking when adding qualifiers to a type.
llvm-svn: 105526
any arguments that are default-argument expressions. The can show up
when we have a new expression whose constructor arguments are not
type-dependent and whose allocated type is not dependent and has a
constructor with default arguments. Fixes PR7202.
llvm-svn: 104690
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
llvm-svn: 103870
for, and switch), be careful to construct the full expressions as soon
as we perform template instantation, so we don't either forget to call
temporary destructors or destroy temporaries at the wrong time. This
is the template-instantiation analogue to r103187, during which I
hadn't realized that the issue would affect the handling of these
constructs differently inside and outside of templates.
Fixes a regression in Boost.Function.
llvm-svn: 103357
if/switch/while/do/for statements. Previously, we would end up either:
(1) Forgetting to destroy temporaries created in the condition (!),
(2) Destroying the temporaries created in the condition *before*
converting the condition to a boolean value (or, in the case of a
switch statement, to an integral or enumeral value), or
(3) In a for statement, destroying the condition's temporaries at
the end of the increment expression (!).
We now destroy temporaries in conditions at the right times. This
required some tweaking of the Parse/Sema interaction, since the parser
was building full expressions too early in many places.
Fixes PR7067.
llvm-svn: 103187
of the mapping from local declarations to their instantiated
counterparts during template instantiation. Previously, we tried to do
some unholy merging of local instantiation scopes that involved
storing a single hash table along with an "undo" list on the
side... which was ugly, and never handled function parameters
properly.
Now, we just keep separate hash tables for each local instantiation
scope, and "combining" two scopes means that we'll look in each of the
combined hash tables. The combined scope stack is rarely deep, and
this makes it easy to avoid the "undo" issues we were hitting. Also,
I've simplified the logic for function parameters: if we're declaring
a function and we need the function parameters to live longer, we just
push them back into the local instantiation scope where we need them.
Fixes PR6990.
llvm-svn: 102732
classes, since we only warn (not error) on offsetof() for non-POD
types. We store the base path within the OffsetOfExpr itself, then
evaluate the offsets within the constant evaluator.
llvm-svn: 102571
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
UnresolvedLookupExpr and UnresolvedMemberExpr by substituting the
naming class we computed when building the expression in the
template...
... which we didn't always do correctly. Teach
UnresolvedMemberExpr::getNamingClass() all about the new
representation of injected-class-names in templates, so that it can
return a naming class that is the current instantiation.
Also, when decomposing a template-id into its template name and its
arguments, be sure to set the naming class on the LookupResult
structure.
Fixes PR6947 the right way.
llvm-svn: 102448
by using TypeSourceInfo, cleaning up the representation
somewhat. Teach getTypeOperand() to strip references and
cv-qualifiers, providing the semantic view of the type without
requiring any extra storage (the unmodified type remains within the
TypeSourceInfo). This fixes a bug found by Boost's call_traits test.
Finally, clean up semantic analysis, by splitting the ActOnCXXTypeid
routine into ActOnCXXTypeId (the parser action) and two BuildCXXTypeId
functions, which perform the semantic analysis for typeid(type) and
typeid(expression), respectively. We now perform less work at template
instantiation time (we don't look for std::type_info again) and can
give better diagnostics.
llvm-svn: 102393
references and isa expressions. Also, test template instantiation of
unresolved member references to Objective-C ivar references and isa
expressions.
llvm-svn: 102374
(e.g., no typename, enum, class, etc.), e.g., because the context is
one that is known to refer to a type. Patch from Enea Zaffanella!
llvm-svn: 102243
statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).
llvm-svn: 102221
method being called at template definition time, retain that method
and pass it through to type-checking. We will not perform any lookup
for the method during template instantiation.
llvm-svn: 102081
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
llvm-svn: 102071
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
nested-name-specifier (e.g., "class T::foo") fails to find a tag
member in the scope nominated by the
nested-name-specifier. Previously, we gave a bland
error: 'Nested' does not name a tag member in the specified scope
which didn't actually say where we were looking, which was rather
horrible when the nested-name-specifier was instantiated. Now, we give
something a bit better:
error: no class named 'Nested' in 'NoDepBase<T>'
llvm-svn: 100060
(such as "class T::foo") from an ElaboratedType of a TypenameType to a
DependentNameType, which more accurately models the underlying
concept.
Improve template instantiation for DependentNameType nodes that
represent nested-name-specifiers, by performing tag name lookup and
checking the resulting tag appropriately. Fixes PR5681.
There is still much testing and cleanup to do in this area.
llvm-svn: 100054
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936
instantiation. Based on a patch by Enea Zaffanella! I found a way to
reduce some of the redundancy between TreeTransform's "standard"
FunctionProtoType transformation and TemplateInstantiator's override,
and I killed off the old SubstFunctionType by adding type source info
for the last cases where we were creating FunctionDecls without TSI
(at least that get passed through template instantiation).
llvm-svn: 98252
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
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
llvm-svn: 97674
used to do this, but it got lost when we switched functional-style
cast syntax over to using the new initialization code. Fixes PR6457.
llvm-svn: 97568
used when we instantiate C++ new expressions, delete expressions, and
object-construction expressions. Fixes PR6424, although we can't test
all of it until we finish implementing lookup of "operator delete" for
new expressions (!).
llvm-svn: 97195
to mark the constructor as referenced. Fixes the narrow issue reported
in PR6424, but there are a few other places that I'll fix before
closing out that PR.
llvm-svn: 97185
compilation using g++ v3.4.
I'll watch the buildbots and back out if necessary.
Feel free to do the same if something breaks.
Without this patch I get (on g++ 3.4.6) following error:
In file included from clang/lib/Sema/SemaTemplate.cpp:14:
clang/lib/Sema/TreeTransform.h: In member function `clang::ASTOwningResult<&clang::ActionBase::DeleteExpr> clang::TreeTransform<Derived>::RebuildCXXPseudoDestructorExpr(clang::ASTOwningResult<&clang::ActionBase::DeleteExpr>, clang::SourceLocation, bool, clang::NestedNameSpecifier*, clang::SourceRange, clang::TypeSourceInfo*, clang::SourceLocation, clang::SourceLocation, clang::PseudoDestructorTypeStorage)':
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before '>' token
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before ')' token
make[4]: *** [clang/lib/Sema/Release/SemaTemplate.o] Error 1
llvm-svn: 97136
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
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
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
llvm-svn: 97045
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
rebuilding a typename type terminating in a template-id (with
dependent template name, naturally) as a TypenameType when, because
its context could be fully resolved, we should have been building it
as a QualifiedNameType. Fixes PR6268.
llvm-svn: 96084
realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.
llvm-svn: 95192
Adjust BuildMemberReferenceExpr to perform the inheritance check on implicit
member accesses, which can arise from unqualified lookups and therefore may
reference decls from enclosing class scopes.
Fixes PR 5838.
llvm-svn: 93510
expressions (e.g., for template instantiation), just transform the
subexpressions and return those, since the temporary-related nodes
will be implicitly regenerated. Fixes PR5867, but I said that
before...
llvm-svn: 92135
a size, check whether the transformed type is itself an array type. If
so, take the major array bound as the size to allocate. Fixes PR5833.
llvm-svn: 91907
- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and we don't want
to instantiate them twice.
- Rewrote the instantiation of variable initializers to cope with
non-dependent forms properly.
Together, these fix a handful of problems I introduced with the switch
to always rebuild expressions from the source code "as written."
llvm-svn: 91315
implicitly-generated AST nodes. We previously built instantiated nodes
for each of these AST nodes, then passed them on to Sema, which was
not prepared to see already-type-checked nodes (see PR5755). In some
places, we had ugly workarounds to try to avoid re-type-checking
(e.g., in VarDecl initializer instantiation).
Now, we skip implicitly-generated nodes when performing instantiation,
preferring instead to build just the AST nodes that directly reflect
what was written in the source code. This has several advantages:
- We don't need to instantiate anything that doesn't have a direct
correlation to the source code, so we can have better location
information.
- Semantic analysis sees the same thing at template instantiation
time that it would see for a non-template.
- At least one ugly hack (VarDecl initializers) goes away.
Fixes PR5755.
llvm-svn: 91218
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
llvm-svn: 91045
horrible isAddressOfOperand hack in TreeTransform, since that syntactic
information is managed by the initial parser callbacks now.
That's enough insomniac commits for one night.
llvm-svn: 90849
intended. On the first testcase in the bug, we now produce:
cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier
y:a a2;
^
::
instead of:
t.cc:8:1: error: C++ requires a type specifier for all declarations
x:a a2;
^
t.cc:8:2: error: invalid token after top level declarator
x:a a2;
^
;
t.cc:9:11: error: use of undeclared identifier 'a2'
x::a a3 = a2;
^
llvm-svn: 90713
implicit member access to a specific declaration, go ahead and create
it as a DeclRefExpr or a MemberExpr (with implicit CXXThisExpr base) as
appropriate. Otherwise, create an UnresolvedMemberExpr or
DependentScopeMemberExpr with a null base expression.
By representing implicit accesses directly in the AST, we get the ability
to correctly delay the decision about whether it's actually an instance
member access or not until resolution is complete. This permits us
to correctly avoid diagnosing the 'problem' of 'MyType::foo()'
where the relationship to the type isn't really known until instantiation.
llvm-svn: 90266
Create a new UnresolvedMemberExpr for these lookups. Assorted hackery
around qualified member expressions; this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.
llvm-svn: 90161
Douglas Gregor