| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
functions that includes an explicit template argument list, perform
an inner deduction against each of the function templates in that list
and, if successful, use the result of that deduction for the outer
template argument deduction. Fixes PR11713.
llvm-svn: 152575
|
|
|
|
|
|
|
|
| |
structural comparison of non-dependent types. Otherwise, we end up
rejecting cases where the non-dependent types don't match due to
qualifiers in, e.g., a pointee type. Fixes PR12132.
llvm-svn: 152529
|
|
|
|
|
|
| |
bug involving packs. Fixes PR12049.
llvm-svn: 151130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
specialization.
llvm-svn: 147798
|
|
|
|
|
|
| |
initialization, not default initialization. Fixes PR11712.
llvm-svn: 147620
|
|
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 146988
|
|
|
|
|
|
| |
declarations without a declarator to structs. Add a warning for ignored attributes. Patch by Michael Han.
llvm-svn: 146796
|
|
|
|
| |
llvm-svn: 144060
|
|
|
|
|
|
|
| |
valid C++98/03 code. However, add these warnings to -Wall, for those
who obviously already like clean code.
llvm-svn: 142903
|
|
|
|
| |
llvm-svn: 142760
|
|
|
|
|
|
| |
in-class member initialisers).
llvm-svn: 142758
|
|
|
|
|
|
| |
gcc's behaviour), and a -Wc++98-compat-pedantic warning for C++11.
llvm-svn: 142597
|
|
|
|
|
|
| |
template with a non-final parameter pack. Also improve the warning for non-final parameter packs in this scenario so it only fires once, rather than once for every template parameter after the non-final parameter pack.
llvm-svn: 142473
|
|
|
|
| |
llvm-svn: 141982
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
part of template argument deduction is ill-formed, we mark it as
invalid and treat it as a deduction failure. If we happen to find that
specialization again, treat it as a deduction failure rather than
silently building a call to the declaration.
Fixes PR11117, a marvelous bug where deduction failed after creating
an invalid specialization, causing overload resolution to pick a
different candidate. Then we performed a similar overload resolution
later, and happily picked the invalid specialization to
call... resulting in a silent link failure.
llvm-svn: 141809
|
|
|
|
|
|
|
|
| |
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.
llvm-svn: 141801
|
|
|
|
|
|
|
|
|
|
|
| |
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
|
|
|
|
|
|
|
| |
where we can't expand (i.e., multi-level substitution), be sure to
substitute the pack with its level-reduced pack. Fixes PR10230.
llvm-svn: 141568
|
|
|
|
|
|
|
| |
argument deduction against a function parameter that has no deducible
template parameters in it. Fixes PR8598.
llvm-svn: 141517
|
|
|
|
|
|
| |
template arguments are dependent. Fixes PR10913.
llvm-svn: 141515
|
|
|
|
|
|
|
|
|
| |
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
llvm-svn: 138821
|
|
|
|
|
|
|
|
|
|
|
|
| |
also contain declarators. Previously we would accept code like this:
template<typename T> struct S { } f() { return 0; }
This case now produces a missing ';' diagnostic, since that seems like a much more likely error than an attempt to declare a function or variable in addition to the class template.
Treat this
llvm-svn: 135195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deducing template parameter types. Recently Clang began enforcing the
more strict checking that the argument type and the deduced function
parameter type (after substitution) match, but that only consideres
qualification conversions.
One problem with this patch is that we check noreturn conversions and
qualification conversions independently. If a valid conversion would
require *both*, perhaps interleaved with each other, it will be
rejected. If this actually occurs (I'm not yet sure it does) and is in
fact a problem (I'm not yet sure it is), there is a FIXME to implement
more intelligent conversion checking.
However, this step at least allows Clang to resume accepting valid code
we're seeing in the wild.
llvm-svn: 133327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checks that the deduced argument type for a function call matches the
actual argument type provided. The only place we've found where the
consistency checking should actually cause template argument deduction
failure is due to qualifier differences that don't fall into the realm
of qualification conversions (which are *not* checked when we
initially perform deduction). However, we're performing the full
checking as specified in the standard to ensure that no other cases
exist.
Fixes PR9233 / <rdar://problem/9039590>.
llvm-svn: 133163
|
|
|
|
|
|
|
|
| |
specializations within an explicit instantiation to default to off
(enabled by -pedantic). Nobody else seem to implement C++
[temp.explicit]p3. Fixes PR10093.
llvm-svn: 132704
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
nested types, from Michael Han!
llvm-svn: 132431
|
|
|
|
|
|
|
| |
manifested in a crash with blocks in PR9953, but it was a ticking time
bomb for normal functions, too. Fixes PR9953.
llvm-svn: 131731
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
argument deduction failures. Only implemented in C++0x, since this is
a significant change in behavior from C++98/03.
llvm-svn: 131209
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
template-id in an alias declaration was meant to be a specialization. Use a generic, but more accurate, diagnostic.
llvm-svn: 130961
|
|
|
|
| |
llvm-svn: 130953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters on the floor in certain cases:
class X {
template <typename T> friend typename A<T>::Foo;
};
This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.
Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.
llvm-svn: 130772
|
|
|
|
|
|
| |
draft standard (N3291).
llvm-svn: 129541
|
|
|
|
|
|
|
|
| |
weak linkage. Also, fix a problem where global weak variables
with non-trivial initializers were getting guard variables, or at
least were checking for them and then crashing.
llvm-svn: 129342
|
|
|
|
|
|
| |
dependent scope and produce an error (rather than crashing). Fixes PR8979.
llvm-svn: 127749
|
|
|
|
|
|
|
|
|
| |
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
llvm-svn: 127747
|
|
|
|
|
|
| |
a...", it appears to cause us to reject various valid codes.
llvm-svn: 127373
|
|
|
|
|
|
| |
dependent scope and produce an error (rather than crashing). Fixes PR8979.
llvm-svn: 127206
|
|
|
|
|
|
|
|
|
|
|
| |
of a C++0x inline namespace within enclosing namespaces, as noted in
C++0x [namespace.def]p8.
Fixes <rdar://problem/9006349>, a libc++ failure where Clang was
rejected an explicit specialization of std::swap (since libc++ puts it
into an inline, versioned namespace std::__1).
llvm-svn: 127162
|