| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
non-dependent.
|
|
|
|
|
|
|
|
|
|
|
| |
This permits an init-capture to introduce a new pack:
template<typename ...T> auto x = [...a = T()] { /* a is a pack */ };
To support this, the mechanism for allowing ParmVarDecls to be packs has
been extended to support arbitrary local VarDecls.
llvm-svn: 361300
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36527
llvm-svn: 359967
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
This reinstates r354091, which was previously reverted in r354097
because it exposed bugs in lldb and compiler-rt. Those bugs were fixed
in r354173 and r354174 respectively.
llvm-svn: 354176
|
|
|
|
|
|
|
|
|
| |
This reverts commit 40bd10b770813bd1471d46f514545437516aa4ba.
This seems to now emit an error when building the sanitizer tests:
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53965/consoleFull.
llvm-svn: 354097
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a template-name is looked up, we need to give injected-class-name
declarations of class templates special treatment, as they denote a
template rather than a type.
Previously we achieved this by applying a filter to the lookup results
after completing name lookup, but that is incorrect in various ways, not
least of which is that it lost all information about access and how
members were named, and the filtering caused us to generally lose
all ambiguity errors between templates and non-templates.
We now preserve the lookup results exactly, and the few places that need
to map from a declaration found by name lookup into a declaration of a
template do so explicitly. Deduplication of repeated lookup results of
the same injected-class-name declaration is done by name lookup instead
of after the fact.
llvm-svn: 354091
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, clang marked the specialization as invalid without emitting a
diagnostic. This lead to an assert in CodeGen.
rdar://41806724
Differential revision: https://reviews.llvm.org/D49085
llvm-svn: 337497
|
|
|
|
|
|
|
| |
Fixes a selection of rejects-valids when pack-expanding a lambda that itself
contains a pack expansion.
llvm-svn: 310972
|
|
|
|
|
|
|
|
|
|
| |
sure that non-template functions don't end up in the candidate set.
Fixes PR14211.
Patch by Don Hinton!
llvm-svn: 304951
|
|
|
|
|
|
|
|
|
|
|
| |
name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we
would fail to notice that the 'typename' keyword is missing when resolving it
to a type.
It turns out that GCC has a similar bug. If this shows up in much real code, we
can easily downgrade this to an ExtWarn.
llvm-svn: 293815
|
|
|
|
|
|
|
|
|
|
| |
to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).
llvm-svn: 290647
|
|
|
|
|
|
|
|
| |
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)
llvm-svn: 290593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other compilers accept invalid code here that we reject, and we need a
better error message to try to convince users that the code is really
incorrect. Consider:
class Foo {
typedef MyIterHelper<Foo> iterator;
friend class iterator;
};
Previously our wording was "elaborated type refers to a typedef".
"elaborated type" isn't widely known terminology, so the new diagnostic
says "typedef 'iterator' cannot be referenced with class specifier".
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D25216
llvm-svn: 289259
|
|
|
|
|
|
| |
C++ language standard is not C++98.
llvm-svn: 280309
|
|
|
|
|
|
|
|
|
|
| |
The problem is that the parameter pack in a function type type alias is not
reexpanded after being transformed. Also remove an incorrect comment in a
similar function. Fixes PR26017.
Differential Revision: http://reviews.llvm.org/D21030
llvm-svn: 274566
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch compiler emits warning if it tries to make implicit instantiation
of a template but cannot find the template definition. The warning can be suppressed
by explicit instantiation declaration or by command line options
-Wundefined-var-template and -Wundefined-func-template. The implementation follows
the discussion of http://reviews.llvm.org/D12326.
Differential Revision: http://reviews.llvm.org/D16396
llvm-svn: 266719
|
|
|
|
|
|
| |
Patch by Erik Pilkington!
llvm-svn: 265571
|
|
|
|
|
|
|
| |
Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 253371
|
|
|
|
| |
llvm-svn: 237652
|
|
|
|
|
|
|
|
|
|
| |
Previously, many error messages would simply be "read-only variable is not
assignable" This change provides more information about why the variable is
not assignable, as well as note to where the const is located.
Differential Revision: http://reviews.llvm.org/D4479
llvm-svn: 234677
|
|
|
|
|
|
|
| |
template partial ordering rules. This rule applies per pair of types being
compared, not per pair of function templates being compared.
llvm-svn: 229965
|
|
|
|
| |
llvm-svn: 222400
|
|
|
|
|
|
|
| |
non-dependent types, in CXXScalarValueInitExprs and in the
nested-name-specifier or template arguments of a DeclRefExpr in particular.
llvm-svn: 220028
|
|
|
|
|
|
| |
dependent scopes.
llvm-svn: 218590
|
|
|
|
|
|
| |
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
|
|
|
|
|
|
|
|
|
|
|
| |
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
|
|
|
|
| |
llvm-svn: 210064
|
|
|
|
| |
llvm-svn: 209955
|
|
|
|
| |
llvm-svn: 203302
|
|
|
|
|
|
|
| |
issue 1430. Don't allow a pack expansion to be used as an argument to an alias
template unless the corresponding parameter is a parameter pack.
llvm-svn: 198833
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
llvm-svn: 198271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
|
|
|
|
|
|
| |
support.
llvm-svn: 194273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enforce the rule in C++11 [temp.mem]p2 that local classes cannot have
member templates.
This fixes PR16947.
N.B. C++14 has slightly different wording to afford generic lambdas
declared inside of functions.
Fun fact: Some formulations of local classes with member templates
would cause clang to crash during Itanium mangling, such as the
following:
void outer_mem() {
struct Inner {
template <typename = void>
struct InnerTemplateClass {
static void itc_mem() {}
};
};
Inner::InnerTemplateClass<>::itc_mem();
}
Reviewers: eli.friedman, rsmith, doug.gregor, faisalv
Reviewed By: doug.gregor
CC: cfe-commits, ygao
Differential Revision: http://llvm-reviews.chandlerc.com/D1866
llvm-svn: 193144
|
|
|
|
|
|
|
|
|
|
|
| |
Now that CorrectTypo knows how to correctly search classes for typo
correction candidates, there is no good reason to only replace an
existing CXXScopeSpecifier if it refers to a namespace. While the actual
enablement was a matter of changing a single comparison, the fallout
from enabling the functionality required a lot more code changes
(including my two previous commits).
llvm-svn: 193020
|
|
|
|
|
|
|
| |
fix to come once I've tracked down the problem (which is pre-existing and not
related to the change which introduced this test).
llvm-svn: 191279
|
|
|
|
|
|
| |
something, for variable templates.
llvm-svn: 191278
|
|
|
|
|
|
|
|
|
|
|
| |
non-member function, the number of arguments in the two candidate calls
will be different (the non-member call will have one extra argument).
We used to get confused by this, and fail to compare the last argument
when testing whether the member is better, resulting in us always
thinking it is, even if the non-member is more specialized in the last
argument.
llvm-svn: 190470
|
|
|
|
|
|
| |
fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...
llvm-svn: 187762
|
|
|
|
| |
llvm-svn: 187734
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r186331).
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This breaks the build of basic patterns with repeated friend
declarations. See the added test case in SemaCXX/friend.cpp or the test
case reported to the original commit log.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186331
|
|
|
|
|
|
|
|
| |
does not substitute a sizeof-pack expression.
The solution is proposed by Richard Smith.
Differential Revision: http://llvm-reviews.chandlerc.com/D869
llvm-svn: 186306
|
|
|
|
|
|
|
|
|
|
|
| |
Test coverage for non-dependent pack expansions doesn't demonstrate a
failure prior to this patch (a follow-up commit improving debug info
will cover this commit specifically) but covers a related hole in our
test coverage.
Reviewed by Richard Smith & Eli Friedman.
llvm-svn: 186261
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186199
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix is.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186185
|
|
|
|
|
|
|
|
|
| |
lookup in the surrounding context. Slightly rework how we handle friend
declarations to inherit the visibility of the prior declaration, rather
than setting a friend declaration to be visible whenever there was a prior
declaration.
llvm-svn: 186040
|
|
|
|
| |
llvm-svn: 184885
|
|
|
|
|
|
| |
and parameter packs
llvm-svn: 184644
|
|
|
|
| |
llvm-svn: 184501
|