Otherwise ClassTemplateSpecializationDecl::getSourceRange() will mistakenly consider itself as an implicit partial specialization
and lead to a crash.
Fixes rdar://14063074
llvm-svn: 183325
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
Otherwise the source range of the explicit instantiation may become invalid (begin location will be after the end location).
rdar://13706991
llvm-svn: 180070
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
This was causing correctness issues for ARC and the static analyzer when a
function template has "consumed" Objective-C object parameters (i.e.
parameters that will be released by the function before returning).
The fix is threefold:
(1) Actually copy over the attributes from old ParmVarDecls to new ones.
(2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes,
which it was doing anyway. This allows us to pass an ExtProtoInfo
instead of a plain ExtInfo and several flags.
(3) Drop param attributes as part of StripImplicitInstantiation, which is
used when an implicit instantiation is followed by an explicit one.
<rdar://problem/12685622>
llvm-svn: 176728
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
llvm-svn: 174242
parameters (per C++ [temp.param]p8) when computing the type of a
reference to a non-type template parameter. Fixes <rdar://problem/13000548>.
llvm-svn: 172585
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
type-name is looked up in the context of the complete postfix-expression. Don't
forget to pass the scope into this lookup when the type-name is a template-id;
it might name an alias template which can't be found within the class itself.
Bug spotted by Johannes Schaub on #llvm.
llvm-svn: 168011
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
llvm-svn: 163369
are not definitions. This follows the behavior of both gcc and earlier
versions of clang. Regression from r156531. <rdar://problem/12048621>.
llvm-svn: 161523
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.
llvm-svn: 160245
-ftemplate-depth limit. There are various ways to get an infinite (or merely
huge) stack of substitutions with no intervening instantiations. This is also
consistent with gcc's behavior.
llvm-svn: 159907
* Escaped "::" and "<" as needed in Doxygen comments;
* Marked up code examples with \code...\endcode;
* Documented a \param that is current, instead of a few that aren't;
* Fixed up some \file and \brief comments.
llvm-svn: 158562
* Removed \param comments for parameters that no longer exist;
* Fixed a "\para" typo to "\param";
* Escaped @, # and \ symbols as needed in Doxygen comments;
* Added use of \brief to output short summaries.
llvm-svn: 158498
* Escape #, < and @ symbols where Doxygen would try to interpret them;
* Fix several function param documentation where names had got out of sync;
* Delete param documentation referring to parameters that no longer exist.
llvm-svn: 158472
The integral APSInt value is now stored in a decomposed form and the backing
store for large values is allocated via the ASTContext. This way its not
leaked as TemplateArguments are never destructed when they are allocated in
the ASTContext. Since the integral data is immutable it is now shared between
instances, making copying TemplateArguments a trivial operation.
Currently getting the integral data out of a TemplateArgument requires creating
a new APSInt object. This is cheap when the value is small but can be expensive
if it's not. If this turns out to be an issue a more efficient accessor could
be added.
llvm-svn: 158150
candidate template ignored: substitution failed [with T = int]: no type named 'type' in 'std::enable_if<false, void>'
Instead, just say:
candidate template ignored: disabled by 'enable_if' [with T = int]
... and point at the enable_if condition which (we assume) failed.
This is applied to all cases where the user writes 'typename enable_if<...>::type' (optionally prefixed with a nested name specifier), and 'enable_if<...>' names a complete class type which does not have a member named 'type', and this results in a candidate function being ignored in a SFINAE context. Thus it catches 'std::enable_if', 'std::__1::enable_if', 'boost::enable_if' and 'llvm::enable_if'.
llvm-svn: 156463
Sema::ConvertToIntegralOrEnumerationType() from PartialDiagnostics to
abstract "diagnoser" classes. Not much of a win here, but we're
-several PartialDiagnostics.
llvm-svn: 156217
[basic.lookup.classref]p1 and p4, which concerns name lookup for
nested-name-specifiers and template names, respectively, in a member
access expression. C++98/03 forces us to look both in the scope of the
object and in the current scope, then compare the results. C++11 just
takes the result from the scope of the object, if something is
found. Fixes <rdar://problem/11328502>.
llvm-svn: 155935
pretend there was no previous declaration -- that can lead us to injecting
a class template (with no access specifier) into a class scope. Instead,
just avoid the problematic checks.
llvm-svn: 155303
up an elaborated type specifier in a friend declaration, only look for type
declarations, per [basic.lookup.elab]p2. If we know that the redeclaration
lookup for a friend class template in a dependent context finds a non-template,
don't delay the diagnostic to instantiation time.
llvm-svn: 155187
the nested-name-specifier (e.g., because it is dependent), do not
error even though we can't represent it in the AST at this point.
This is a horrible, horrible hack. The actual feature we still need to
implement (for C++98!) is covered by PR12292. However, we used to
silently accept this code, so when we recently started rejecting it we
caused some regressions (e.g., <rdar://problem/11147355>). This hack
brings us back to the passable-but-not-good state we had previously.
llvm-svn: 153752
concerning qualified declarator-ids. We now diagnose extraneous
qualification at namespace scope (which we had previously missed) and
diagnose these qualification errors for all kinds of declarations; it
was rather uneven before. Fixes <rdar://problem/11135644>.
llvm-svn: 153577
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
access expression is the start of a template-id, ignore function
templates found in the context of the entire postfix-expression. Fixes
PR11856.
llvm-svn: 152520
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
* Handle some situations where we should never make a decl more visible,
even when merging in an explicit visibility.
* Handle attributes in members of classes that are explicitly specialized.
Thanks Nico for the report and testing, Eric for the initial review, and dgregor
for the awesome test27 :-)
llvm-svn: 151236
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
llvm-svn: 151001
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:
- Added new entry points for TreeTransform, so that we can
explicitly establish the link between the lambda closure type in the
template and the lambda closure type in the instantiation.
- Added a bit into LambdaExpr specifying whether it had an explicit
result type or not. We should have had this anyway.
This code is 'lightly' tested.
llvm-svn: 150417
The new info is propagated to TSTLoc on template instantiation, getting rid of 3 FIXMEs in TreeTransform.h and another one Parser.cpp.
Simplified code in TypeSpecLocFiller visitor methods for DTSTLoc and DependentNameTypeLoc by removing what now seems to be dead code (adding corresponding assertions).
llvm-svn: 149923
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
template without a corresponding parameter pack, don't immediately
substitute the alias template. This is under discussion in the C++
committee, and may become ill-formed, but for now we match GCC.
llvm-svn: 149697
template. Such pack expansions can easily fail at template
instantiation time, if the expanded parameter packs are of the wrong
length. Fixes <rdar://problem/10040867>, PR9021, and the example that
came up today at Going Native.
llvm-svn: 149685
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
llvm-svn: 148187
virtual functions that provide previous/most recent redeclaration
information for any declaration. Use this to eliminate the redundant,
less efficient getPreviousDecl() functions.
llvm-svn: 148184
The change to SemaTemplateVariadic.cpp improves the typo correction
results in certain situations, while the change to SemaTemplate.cpp
does not change existing behavior.
llvm-svn: 148155
expression for an Objective-C object or pointer type, so that we don't
attempt to treat the member name as a template. Fixes
<rdar://problem/10672501>.
llvm-svn: 148028
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
Explicit instantiations following specializations are no-ops and hence have
no PointOfInstantiation. That was done correctly in most cases, but for a
specialization -> instantiation decl -> instantiation definition chain, the
definition didn't realize that it was a no-op. Fix that.
Also, when printing diagnostics for these no-ops, get the diag location from
the decl name location.
Add many test cases, one of them not yet passing (but it failed the same way
before this change). Fixes http://llvm.org/pr11558 and more.
llvm-svn: 147225
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
llvm-svn: 146980
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
definition, we may not have a scope corresponding to the namespace
where that friend function template actually lives. Work around this
issue by faking up a scope with the appropriate DeclContext.
This is a bit of a hack, but it fixes <rdar://problem/10204947>.
llvm-svn: 143614
does not match any declaration in the class (or class template), be
sure to mark it as invalid. Fixes PR10924 / <rdar://problem/10119422>.
llvm-svn: 143504
rvalue. An assertion to catch this is in ImpCastExprToType will follow, but
vector operations currently trip over this (due to omitting the usual arithmetic
conversions). Also add an assert to catch missing lvalue-to-rvalue conversions
on the LHS of ->.
llvm-svn: 143155
Microsoft __if_exists/__if_not_exists statement. Also note that we
weren't traversing DeclarationNameInfo *at all* within the
RecursiveASTVisitor, which would be rather fatal for variadic
templates.
llvm-svn: 142906
shadows a template parameter. Complain about the shadowing (or not,
under -fms-extensions), but don't invalidate the declaration. Merely
forget about the template parameter declaration.
llvm-svn: 142596
the right namespace in C++11 mode. Teach the code to prefer the 'must be in
precisely this namespace' diagnostic whenever that's true, and fix a defect
which resulted in the -Wc++11-compat warning in C++98 mode sometimes being
omitted.
llvm-svn: 142329
Much to everyone's surprise, the default constructor for TypeResult produces
an instance with Invalid == false. This seems like a decision we may want to
revisit.
llvm-svn: 138601
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
llvm-svn: 137573
a member template, e.g.,
x.f<int>
if we have found a template in the type of x, but the lookup in the
current scope is ambiguous, just ignore the lookup in the current
scope. Fixes <rdar://problem/9915664>.
llvm-svn: 137255
which is required given the current setup for template
argument deduction substitution validation, and add a test
case to make sure we don't break it in the future.
llvm-svn: 135262
to represent a fully-substituted non-type template parameter.
This should improve source fidelity, as well as being generically
useful for diagnostics and such.
llvm-svn: 135243
type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).
When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.
In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,
template<unsigned> struct A { };
template<typename T>
void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
template void f<int>(A<sizeof(sizeof(int))>);
and therefore get the wrong answer.
llvm-svn: 134225
for a template template parameter.
Uses to follow.
I've also made the uniquing of SubstTemplateTemplateParmPacks
use a ContextualFoldingSet as a minor space efficiency.
llvm-svn: 134137
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
ownership-unqualified retainable object type as __strong. This allows
us to write, e.g.,
std::vector<id>
and we'll infer that the vector's element types have __strong
ownership semantics, which is far nicer than requiring:
std::vector<__strong id>
Note that we allow one to override the ownership qualifier of a
substituted template type parameter, e.g., given
template<typename T>
struct X {
typedef __weak T type;
};
X<id> is treated the same as X<__strong id>. At instantiation type,
the __weak in "__weak T" overrides the (inferred or specified)
__strong on the template argument type, so that we can still provide
metaprogramming transformations.
This is part of <rdar://problem/9595486>.
llvm-svn: 133303
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
before the template parameters have acquired a proper context (e.g.,
because the enclosing context has yet to be built), provide empty
parameter lists for all outer template parameter scopes to inhibit any
substitution for those template parameters. Fixes PR9643 /
<rdar://problem/9251019>.
llvm-svn: 133055
- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree. Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.
llvm-svn: 132831
specializing a member of an unspecialized template, and recover from
such errors without crashing. Fixes PR10024 / <rdar://problem/9509761>.
llvm-svn: 132677
the template parameter, perform the checking as a "specified" template
argument rather than a "deduced" template argument; the latter implies
stricter type checking that is not permitted for default template
arguments.
Also, cleanup our handling of substitution of explicit template
arguments for a function template. We were actually performing some
substitution of default arguments at this point!
Fixes PR10069.
llvm-svn: 132529
parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.
Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.
Fixes <rdar://problem/9123036>.
llvm-svn: 132171
type that turns one type into another. This is used as the basis to
implement __underlying_type properly - with TypeSourceInfo and proper
behavior in the face of templates.
llvm-svn: 132017
minor issues along the way:
- Non-type template parameters of type 'std::nullptr_t' were not
permitted.
- We didn't properly introduce built-in operators for nullptr ==,
!=, <, <=, >=, or > as candidate functions .
To my knowledge, there's only one (minor but annoying) part of nullptr
that hasn't been implemented: catching a thrown 'nullptr' as a pointer
or pointer-to-member, per C++0x [except.handle]p4.
llvm-svn: 131813
Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.
Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.
llvm-svn: 131735
nested-name-specifier, re-evaluate the nested-name-specifier as if we
were entering that context (which we did!), so that we'll resolve a
template-id to a particular class template partial
specialization. Fixes PR9913.
llvm-svn: 131383
template<class U>
struct X1 {
template<class T> void f(T*);
template<> void f(int*) { }
};
Won't be so simple. I need to think more about it.
llvm-svn: 131362
template parameter lists to scope specifiers for friend declarations
about injected class name types. Fixes the
g++.dg/template/memfriend5.C regression in the GCC testsuite.
llvm-svn: 131272
nested of an out-of-line declaration, only require a 'template<>'
header for each enclosing class template that hasn't been previously
specialized; previously, we were requiring 'template<>' for enclosing
class templates and members of class templates that hadn't been
previously specialized. Fixes <rdar://problem/9422013>.
llvm-svn: 131207
the semantic context referenced by the nested-name-specifier rather
than the syntactic form of the nested-name-specifier. The previous
incarnation was based on my complete misunderstanding of C++
[temp.expl.spec]. The latest C++0x working draft clarifies the
requirements here, and this rewrite is intended to follow that.
Along the way, improve source location information in the
diagnostics. For example, if we report that a specific type needs or
doesn't need a 'template<>' header, we dig out that type in the
nested-name-specifier and highlight its range.
Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and
<rdar://problem/9135379>.
llvm-svn: 131138
accompanying fixes to make it work today.
The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.
To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.
A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.
This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.
llvm-svn: 130628
This idiom is used everywhere in MFC/COM code and as such this patch removes hundreds of errors when parsing MFC code with clang.
Example:
template <class T, const GUID* g = &__uuidof(T)>
class ComTemplate { };
typedef ComTemplate<struct_with_uuid, &__uuidof(struct_with_uuid)> COM_TYPE;
Of course this is just parsing support. Trying to use this in CodeGen will generate:
error: cannot yet mangle expression type CXXUuidofExpr
llvm-svn: 130381
in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.
llvm-svn: 130288
performs name lookup for an identifier and resolves it to a
type/expression/template/etc. in the same step. This scheme is
intended to improve both performance (by reducing the number of
redundant name lookups for a given identifier token) and error
recovery (by giving Sema a chance to correct type names before the
parser has decided that the identifier isn't a type name). For
example, this allows us to properly typo-correct type names at the
beginning of a statement:
t.c:6:3: error: use of undeclared identifier 'integer'; did you mean
'Integer'?
integer *i = 0;
^~~~~~~
Integer
t.c:1:13: note: 'Integer' declared here
typedef int Integer;
^
Previously, we wouldn't give a Fix-It because the typo correction
occurred after the parser had checked whether "integer" was a type
name (via Sema::getTypeName(), which isn't allowed to typo-correct)
and therefore decided to parse "integer * i = 0" as an expression. By
typo-correcting earlier, we typo-correct to the type name Integer and
parse this as a declaration.
Moreover, in this context, we can also typo-correct identifiers to
keywords, e.g.,
t.c:7:3: error: use of undeclared identifier 'vid'; did you mean
'void'?
vid *p = i;
^~~
void
and recover appropriately.
Note that this is very much a work-in-progress. The new
Sema::ClassifyName is only used for expression-or-declaration
disambiguation in C at the statement level. The next steps will be to
make this work for the same disambiguation in C++ (where
functional-style casts make some trouble), then push it
further into the parser to eliminate more redundant name lookups.
Fixes <rdar://problem/7963833> for C and starts us down the path of
<rdar://problem/8172000>.
llvm-svn: 130082
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.
llvm-svn: 127037
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.
Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).
How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?
I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.
llvm-svn: 127004
template <class T> void foo();
template <> void foo<int>(); /* Spec 1 */
template <> void foo<int>(); /* Spec 2 */
If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1.
Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location).
llvm-svn: 127002
parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.
This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.
llvm-svn: 126920
template arguments. I believe that this is the last place in the AST
where we were storing a source range for a nested-name-specifier
rather than a proper nested-name-specifier location structure. (Yay!)
There is still a lot of cleanup to do in the TreeTransform, which
doesn't take advantage of nested-name-specifiers with source-location
information everywhere it could.
llvm-svn: 126844
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:
- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.
- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.
- Sema::ActOnDependentTag now creates types with source-location
information.
llvm-svn: 126808
template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name-specifiers too early.
llvm-svn: 126776
nested-name-speciciers within elaborated type names, e.g.,
enum clang::NestedNameSpecifier::SpecifierKind
Fixes in this iteration include:
(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression
dep->template f<T>::f()
This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...
(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.
llvm-svn: 126765
a dependent template name rather than (indirectly and incorrectly)
trying to determine whether we can compute a context for the
nested-name-specifier. Fixes a GCC testsuite regression,
<rdar://problem/9068589>.
llvm-svn: 126749
information for qualifier type names throughout the parser to address
several problems.
The commit message from r126737:
Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
llvm-svn: 126748
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
llvm-svn: 126737
DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to
walk DependentNameTypeLoc nodes.
Also, teach libclang about TypedefDecl source ranges, so that we get
those. The massive churn in test/Index/recursive-cxx-member-calls.cpp
is a good thing: we're annotating a lot more of this test correctly
now.
llvm-svn: 126729
source-location information. We don't actually preserve this
information in any of the resulting TypeLocs (yet), so it doesn't
matter.
llvm-svn: 126693
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
llvm-svn: 126681
CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.
llvm-svn: 126663
dependent template names. There is still a lot of redundant code in
TreeTransform to cope with TemplateSpecializationTypes, which I'll
remove in stages.
llvm-svn: 126656
specifiers such as
typename T::template apply<U>
Previously, we would turn T::template apply<U> into a
TemplateSpecializationType. Then, we'd reprocess that
TemplateSpecializationType and turn it into either a
TemplateSpecializationType wrapped in an ElaboratedType (when we could
resolve "apply" to a template declaration) or a
DependentTemplateSpecializationType. We now produce the same ASTs but
without generating the intermediate TemplateSpecializationType.
The end goal here is to avoid generating TemplateSpecializationTypes
with dependent template-names, ever. We're not there yet.
llvm-svn: 126589
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the
extremely-lossy NestedNameSpecifier/SourceRange pair it used to use,
improving source-location information.
Various infrastructure updates to support NestedNameSpecifierLoc:
- AST/PCH (de-)serialization
- Recursive AST visitor
- libclang traversal (including the first tests of this
functionality)
llvm-svn: 126459
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
includes explicitly-specified template arguments) to a function
template specialization in cases where no deduction is performed or
deduction fails. Patch by Faisal Vali, fixes PR7505!
llvm-svn: 126048
enumeration type, we were generating an integer literal implicitly
casted to the appropriate enumeration type. However, later checks on
that expression would strip the implicit cast.
This commit tweaks the lame hack, by creating an explicit cast instead
of an implicit cast. The right answer is to introduce a
SubstNonTypeTemplateParmExpr expression that acts like the substituted
result. I'll investigate that soon.
llvm-svn: 125818
it's okay for the following template parameters to not have default
arguments (since those template parameters can still be
deduced). Also, downgrade the error about default template arguments
in function templates to an extension warning, since this is a
harmless C++0x extension.
llvm-svn: 124855
argument but doesn't (because previous template parameters had default
arguments), clear out all of the default arguments so that we maintain
the invariant that a template parameter has a default argument only if
subsequence template parameters also have default arguments.
Fixes a crash-on-invalid <rdar://problem/8913649>.
llvm-svn: 124345
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
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
implementation used by overload resolution to support rvalue
references. The original commits caused PR9026 and some
hard-to-reproduce self-host breakage.
The only (crucial!) difference between this commit and the previous
commits is that we now properly check the SuppressUserConversions flag
before attempting to perform a second user-defined conversion in
reference binding, breaking the infinite recursion chain of
user-defined conversions.
Rvalue references should be working a bit better now.
llvm-svn: 124121
resolution to match the latest C++0x working paper's semantics. The
implementation now matching up with the reference-binding
implementation used for initialization.
llvm-svn: 123977
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
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
when we're actually matching a template template argument to a
template template parameter. Otherwise, use strict matching.
Fixes <rdar://problem/8859985> clang++: variadics and out-of-line definitions.
llvm-svn: 123385
matching of variadic template template parameters to template
arguments. This paragraph was the subject of ISO C++ committee
document N2555: Extending Variadic Template Template Parameters.
llvm-svn: 123348
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
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
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
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
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
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
to cope with parameter packs. This is a band-aid I will be
revisiting this section when I implement declaration matching
semantics for variadic templates.
llvm-svn: 122369
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
a parameter pack, check the parameter pack against each of the
template arguments it corresponds to, then pack the converted
arguments into a template argument pack. Allows us to use variadic
class templates so long as instantiation isn't required, e.g.,
template<typename... Types> struct Tuple;
Tuple<int, float> *t2;
llvm-svn: 122251
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
non-type template parameters until we know that we have an actual
template declaration of some sort. This cannot be tested yet, but will
become important when we have template template parameter packs.
llvm-svn: 121967
BuildExpressionFromIntegralTemplateArgument can produce malformed
IntegerLiterals with an EnumType if the template parameter type
is an EnumType. This breaks the AST printer which expects all
IntegerLiterals to have a plain integer type. Instead, give the
IntegerLiteral the enum's promotion type and wrap in an implicit cast
to the EnumType.
llvm-svn: 121862
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
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
We should not substitute template types if the template has a dependent
context because the template argument stack is not yet fully formed.
Instead, defer substitution until the template has a non-dependent
context (i.e. instantiation of an outer template).
llvm-svn: 121491
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
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
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
- 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
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
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
themselves have no template parameters. This is actually a restriction
due to the grammar of template template parameters, but we choose to
diagnose it in Sema to provide better recovery.
llvm-svn: 117032
by marking the decl invalid isn't. Make some steps towards supporting these
and then hastily shut them down at the last second by marking them as
unsupported.
llvm-svn: 116661
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
that are suppressed during template argument deduction. This change
queues diagnostics computed during template argument deduction. Then,
if the resulting function template specialization or partial
specialization is chosen by overload resolution or partial ordering
(respectively), we will emit the queued diagnostics at that point.
This addresses most of PR6784. However, the check for unnamed/local
template arguments (which existed before this change) is still only
skin-deep, and needs to be extended to look deeper into types. It must
be improved to finish PR6784.
llvm-svn: 116373
of templated-scope friends by marking them invalid and white-listing all
accesses until such time as we implement them. Fixes a crash, this time
without a broken test case.
llvm-svn: 116364
error to a warning if we're in a case that would be allowed in
C++0x. This "fixes" PR8084 by making Clang accept more code than GCC
and (non-strict) EDG do.
Also, add the missing test case for the C++0x semantics, which should
have been in r113717.
llvm-svn: 113718
libclang. This includes:
- Cursor kind for function templates, with visitation logic
- Cursor kinds for template parameters, with visitation logic
- Visitation logic for template specialization types, qualified type
locations
- USR generation for function templates, template specialization
types, template parameter types.
Also happens to fix PR7804, which I tripped across while testing.
llvm-svn: 112604
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
templates when only the declaration is in scope. This requires deferring the
instantiation to be lazy, and ensuring the definition is required for that
translation unit. We re-use the existing pending instantiation queue,
previously only used to track implicit instantiations which were required to be
lazy. Fixes PR7979.
A subsequent change will rename *PendingImplicitInstantiations to
*PendingInstatiations for clarity given its broader role.
llvm-svn: 112037
- 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
Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.
Some other notes about newly-generated attribute classes:
- The constructor arguments are a SourceLocation and a Context&,
followed by the attributes arguments in the order that they were
defined in Attr.td
- Every argument in Attr.td has an appropriate accessor named getFoo,
and there are sometimes a few extra ones (such as to get the length
of a variadic argument).
Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.
llvm-svn: 111455
Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.
llvm-svn: 111086
qua templates. The current fix suppresses the access check entirely
in this case; to do better, we'd need to be able to say that a
particular lookup result came from a particular injected class name,
which is not easy to do with the current representation of LookupResult.
This is on my known-problems list.
llvm-svn: 111009
just means "not a function type", not "not a function type or void". This
changes behavior slightly, but generally in a way which accepts more code.
llvm-svn: 110303
leaks though) and add methods to its interface for adding/finding specializations.
Simplifies its users a bit and we no longer need to replace specializations in the folding set with
their redeclarations. We just return the most recent redeclarations.
As a bonus, it fixes http://llvm.org/PR7670.
llvm-svn: 108832
expression such as the "foo" in "this->blah.foo<1, 2>", and we can't
look into the type of "this->blah" (e.g., because it is dependent),
look into the local scope of a template of the same name. Fixes
<rdar://problem/8198511>.
llvm-svn: 108531
definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.
llvm-svn: 108372
class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.
llvm-svn: 108217
parameters starts at the end of the template-parameter rather than at
the point where the template parameter name is encounted. For example,
given:
typedef unsigned char T;
template<typename T = T> struct X0 { };
The "T" in the default argument refers to the typedef of "unsigned
char", rather than referring to the newly-introduced template type
parameter 'T'.
Addresses <rdar://problem/8122812>.
llvm-svn: 107354
(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
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071
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
a member template, and you try to call the member template with an explicit
template argument. See PR7247
For example, this downgrades the error to a warning in:
template<typename T> struct set{};
struct Value {
template<typename T>
void set(T value) {
}
};
void foo() {
Value v;
v.set<double>(3.2); // Warning here.
}
llvm-svn: 105518
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
llvm-svn: 104471
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
llvm-svn: 104443
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
llvm-svn: 104409
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
llvm-svn: 104406
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Fixes PR7114 and PR6564.
llvm-svn: 103718
explicit instantiations of template. C++0x clarifies the intent
(they're ill-formed in some cases; see [temp.explicit] for
details). However, one could squint at the C++98/03 standard and
conclude they are permitted, so reduce the error to a warning
(controlled by -Wc++0x-compat) in C++98/03 mode.
llvm-svn: 103482
different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.
Should fix the last remaining Boost.Accumulors failure.
llvm-svn: 103144
ParseOptionalCXXScopeSpecifier() only annotates the subset of
template-ids which are not subject to lexical ambiguity. Add support
for the more general case in ParseUnqualifiedId() to handle cases
such as A::template B().
Also improve some diagnostic locations.
Fixes PR7030, from Alp Toker!
llvm-svn: 103081
parameter with pointer-to-member type, we may have to perform a
qualification conversion, since the pointee type of the parameter
might be more qualified than the pointee type of the argument we form
from the declaration. Fixes PR6986.
llvm-svn: 102777
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
specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.
llvm-svn: 102693
entering the current instantiation. Set up a little to preserve type location
information for typename types while we're in there.
Fixes a Boost failure.
llvm-svn: 102673
bindings when the template argument is still an expression; it happens
while checking the template arguments of a class template partial
specializations. Fixes PR6964.
llvm-svn: 102595
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
llvm-svn: 102407
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.
llvm-svn: 102247
(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
a qualified name. We weren't checking for an empty
nested-name-specifier when dealing with friend class templates
(although we were checking in the other places where we deal with this
paragraph). Fixes a Boost.Serialization showstopper.
llvm-svn: 101724
intended for redeclarations, fixing those that need it. Fixes PR6831.
This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).
llvm-svn: 101419
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
llvm-svn: 101412
ResolveAddressOfOverloadedFunction when asked to complain. Previously,
we had some weird handshake where ResolveAddressOfOverloadedFunction
expected its caller to handle some of the diagnostics but not others,
and yet there was no way for the caller to know which case we were
in. Eliminate this madness, fixing <rdar://problem/7765884>.
llvm-svn: 101312
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
llvm-svn: 101274
name-lookup ambiguities when there are multiple base classes that are
all specializations of the same class template. This is part of a
general cleanup for ambiguities in template-name lookup. Fixes
PR6717.
llvm-svn: 101065
specializations when the explicit instantiation was... explicitly
written, i.e., not the product of an explicit instantiation of an
enclosing class. Fixes this spurious warning when Clang builds LLVM:
/Volumes/Data/dgregor/Projects/llvm/lib/CodeGen/MachineDominators.cpp:22:1:
warning: explicit instantiation of 'addRoot' that occurs after an
explicit specialization will be ignored (C++0x extension) [-pedantic]
llvm-svn: 100900
parameter, explicitly ask the user to give it arguments. We used to
complain that it wasn't a type and expect the user to figure it out.
llvm-svn: 100729
an object or function. Our previous checking was too lax, and ended up
allowing missing or extraneous address-of operators, among other
evils. The new checking provides better diagnostics and adheres more
closely to the standard.
Fixes PR6563 and PR6749.
llvm-svn: 100125
(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
