| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.
This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case).
Fixes <rdar://problem/9676205>.
llvm-svn: 143551
|
|
|
|
|
|
|
|
|
| |
that it retains source location information for the type. Aside from
general goodness (being able to walk the types described in that
information), we now have a proper representation for dependent
delegating constructors. Fixes PR10457 (for real).
llvm-svn: 143410
|
|
|
|
| |
llvm-svn: 143295
|
|
|
|
|
|
| |
be implicitly instantiated (resulting in a redefinition) in C++98.
llvm-svn: 142468
|
|
|
|
|
|
| |
Richard already fixed the underlying issue, so the cast was superfluous.
llvm-svn: 142192
|
|
|
|
|
|
| |
the underlying issue eventually, but this interface will probably change anyway.
llvm-svn: 142142
|
|
|
|
| |
llvm-svn: 141610
|
|
|
|
|
|
|
| |
a boolean value and check that it is a constant expression. Fixes
PR11084.
llvm-svn: 141511
|
|
|
|
| |
llvm-svn: 141496
|
|
|
|
| |
llvm-svn: 141486
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
llvm-svn: 140926
|
|
|
|
|
|
|
|
|
|
|
| |
correctly pass
the information on to Sema. There's still an incorrectness in the way template instantiation
works now, but that is due to a far larger underlying representational problem.
Also add a test case for various list initialization cases of scalars, which test this
commit as well as the previous one.
llvm-svn: 140460
|
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
| |
Sema::CheckParameterPacksForExpansion
llvm-svn: 140290
|
|
|
|
| |
llvm-svn: 140268
|
|
|
|
|
|
| |
CXXBaseSpecifier, CXXCtorInitializer, NestedNameSpecifier, TemplateParameterList and removed their typedefs.
llvm-svn: 139350
|
|
|
|
|
|
|
|
|
|
|
| |
implicitly instantiable, even if we don't see a body on the friend
function declaration. The body may simply have not yet been attached.
This fixes PR10666.
There may be an alternate, preferred implementation strategy, see my
FIXME. Review would definitely be appreciated Doug. =D
llvm-svn: 137934
|
|
|
|
| |
llvm-svn: 137653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
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
|
|
|
|
|
|
|
|
| |
point, ASTReader::InitializeSema() has very little interesting work,
*except* issues stemming from preloaded declarations. That's something
we'll still need to cope with.
llvm-svn: 136378
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
| |
non-value-dependent cases.
llvm-svn: 135543
|
|
|
|
|
|
|
|
| |
instantiating functions.
Fixes PR10272.
llvm-svn: 134491
|
|
|
|
|
|
|
| |
instantiated function template was written with a prototype or via
some kind of typedef. Fixes PR10273 / <rdar://problem/9723679>.
llvm-svn: 134426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
via a typedef of a function, make sure to synthesize parameter
declarations. Fixes PR9654 / <rdar://problem/9257497>.
llvm-svn: 133628
|
|
|
|
|
|
| |
template definition and each instantiation.
llvm-svn: 133580
|
|
|
|
| |
llvm-svn: 132878
|
|
|
|
|
|
|
|
|
| |
of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.
llvm-svn: 132530
|
|
|
|
|
|
|
| |
constant-expression, and, therefore, an unevaluated operand. Make it
so.
llvm-svn: 132400
|
|
|
|
|
|
|
|
|
| |
vtables! Fixes PR10020
This also allows us to revert the part of r130023 which added a big loop around
the template instantiation.
llvm-svn: 132331
|
|
|
|
|
|
|
|
|
| |
nontemplate in Sema::InstantiateTemplateDecl.
This should make the issue in PR10026 more visible, although it's not
going to fix it because something is violating this precondition.
llvm-svn: 132208
|
|
|
|
| |
llvm-svn: 132175
|
|
|
|
|
|
| |
Pattern is not. Thanks Nick for catching this!
llvm-svn: 132089
|
|
|
|
|
|
|
|
|
|
| |
issues and also add a test.
We should now handle defaulted members of templates properly. No
comment as to whether or not this also holds for templated functions,
but defaulting those is kind of insane.
llvm-svn: 131938
|
|
|
|
|
|
|
|
| |
The general out-of-line case (including explicit instantiation mostly
works except that the definition is being lost somewhere between the AST
and CodeGen, so the definition is never emitted.
llvm-svn: 131933
|
|
|
|
|
|
|
|
| |
fixes PR9965, but we're not out of the water yet, as we do not
successfully handle out-of-line definitions, due to my utter
misunderstanding of how we manage templates.
llvm-svn: 131920
|
|
|
|
| |
llvm-svn: 131222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New isDefined() function checks for deletedness
- isThisDeclarationADefinition checks for deletedness
- New doesThisDeclarationHaveABody() does what
isThisDeclarationADefinition() used to do
- The IsDeleted bit is not propagated across redeclarations
- isDeleted() now checks the canoncial declaration
- New isDeletedAsWritten() does what it says on the tin.
- isUserProvided() now correct (thanks Richard!)
This fixes the bug that we weren't catching
void foo() = delete;
void foo() {}
as being a redefinition.
llvm-svn: 131013
|
|
|
|
|
|
|
| |
direction and not introduce things in the wrong place three different
times.
llvm-svn: 130968
|
|
|
|
| |
llvm-svn: 130953
|
|
|
|
|
|
| |
There's some unused stuff for now.
llvm-svn: 130912
|
|
|
|
|
|
|
|
|
| |
Invalid that was never read from again, causing non-type-template-parms to be
marked valid when in fact they weren't.
This was caught by GCC 4.6's -Wunused-but-set-variable warning.
llvm-svn: 130680
|
|
|
|
|
|
|
|
|
|
| |
parameter node and use this to correctly mangle parameter
references in function template signatures.
A follow-up patch will improve the storage usage of these
fields; here I've just done the lazy thing.
llvm-svn: 130669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 130058
|
|
|
|
|
|
|
|
| |
new templates that need to be instantiated and vice-versa. Iterate
until we've instantiated all required templates and defined all
required vtables. Fixed PR9325 / <rdar://problem/9055177>.
llvm-svn: 130023
|
|
|
|
|
|
|
|
|
| |
function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup.
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
llvm-svn: 130022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
warnings diverge from
gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context
(e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed
is somewhat misleading.
- Don't emit 'unused' warnings for functions that are referenced in any part of the user's code.
- A warning that an internal function/variable won't get emitted is useful though, so introduce
-Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not
"needed" ('used' from the codegen perspective), e.g:
static void foo() { }
template <int>
void bar() {
foo();
}
test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted
static void foo() { }
^
Addresses rdar://8733476.
llvm-svn: 129794
|