Граф коммитов

926 Коммитов

Автор SHA1 Сообщение Дата
Richard Smith b9c6261d02 Improvements to vexing-parse warnings. Make the no-parameters case more
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.

Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160998 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-30 21:30:52 +00:00
Richard Smith b9d0b76e42 Final piece of core issue 1330: delay computing the exception specification of
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).

EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.

This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.

The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.

Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160847 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-27 04:22:15 +00:00
Richard Smith aa488ea287 More for PR11848: a pack expansion type isn't necessarily type-dependent (its
pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160246 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-16 01:59:26 +00:00
Richard Smith 7e54fb5fcc PR13365: Fix code which was trying to treat an array of DeducedTemplateArgument
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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160245 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-16 01:09:10 +00:00
Richard Smith d8672ef2d3 Related to PR11848 and core-21989: switch ContainsUnexpandedParameterPack from
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160244 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-16 00:20:35 +00:00
Richard Smith f5baeb4af5 PR13368: Halve the instantiation depth of this test again. Apparently, FreeBSD
has a much lower default stack limit than the systems I have access to.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160240 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-15 23:29:50 +00:00
Richard Smith 838925dc84 Provide a special-case diagnostic when two class member functions instantiate
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160161 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-13 04:12:04 +00:00
Richard Smith 6098381c29 PR13136:
* When substituting a reference to a non-type template parameter pack where the
   corresponding argument is a pack expansion, transform into an expression
   which contains an unexpanded parameter pack rather than into an expression
   which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
   to be inside the PackExpansionExpr, rather than outside, so the expression
   still looks like a pack expansion and can be deduced.

 * Teach MarkUsedTemplateParameters that we can deduce a reference to a template
   parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
   added during alias template substitution).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159922 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-09 03:07:20 +00:00
Richard Smith 6ff6cfe696 Halve template depth in an attempt to get this test passing on mingw32.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159917 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-08 21:06:29 +00:00
NAKAMURA Takumi fff457fc28 test/SemaTemplate/instantiation-depth-defarg.cpp: Mark as XFAIL:mingw for now.
I'll try to increase stack size later.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159912 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-08 09:35:16 +00:00
Richard Smith 5a343d7856 PR13243: When deducing a non-type template parameter which is specified as an
expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159909 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-08 04:37:51 +00:00
Richard Smith ab91ef1dbe PR9793: Treat substitution as an instantiation step for the purpose of the
-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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159907 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-08 02:38:24 +00:00
Richard Smith ff817f7070 When marking virtual functions as used for a class' vtable, mark all functions
which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159895 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-07 06:59:51 +00:00
Nico Weber 6b02009359 Make explicit specializations at class scope work
for non-type template parameters in microsoft mode.
PR12709.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159147 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-25 17:21:05 +00:00
Nico Weber 94c4d61625 Show fixit for unqualified calls to methods of dependent bases
when the calling site is a member function template.

Effectively reverts r111675.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159004 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-22 16:39:39 +00:00
Nico Weber 4b554f4756 Allow unqualified lookup of non-dependent member functions
in microsoft mode. Fixes PR12701.

The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158842 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-20 20:21:42 +00:00
Richard Smith ca5233044e PR13064: Store whether an in-class initializer uses direct or copy
initialization, and use that information to produce the right kind of
initialization during template instantiation.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158288 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-10 03:12:00 +00:00
Kaelyn Uhrain 8c14de8318 Fix up the 'typename' suggestion logic introduced in r157085, based on
feedback from Doug Gregor.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158185 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-08 01:07:26 +00:00
Simon Atanasyan d95e95ec53 Replace inline asm constraint "=a" by the more general constraint "=r".
That extend a range of platforms support this test case.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157247 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-22 11:03:10 +00:00
Eli Friedman d21016f0b6 Make delegating initializers use a similar codepath to base initializers in dependent contexts. PR12890.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157136 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-19 23:35:23 +00:00
Kaelyn Uhrain ab7ad72f43 Suggest adding 'typename' when it would make the compiler
accept the template argument expression as a type.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157085 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-18 23:42:49 +00:00
David Blaikie be0ee875d8 Improve some of the conversion warnings to fire on conversion to bool.
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.

Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156826 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-15 16:56:36 +00:00
Richard Smith 83a22ecbf5 Recover properly if a class member declaration starts with a scope specifier
or template-id which can't be parsed.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156468 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-09 08:23:23 +00:00
Richard Smith 4493c0aa8a A little tweak to the SFINAE condition reporting. Don't say:
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'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156463 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-09 05:17:00 +00:00
Richard Smith b8590f3572 When we suppress an error due to SFINAE, stash the diagnostic away with the
overload candidate, and include its message in any subsequent 'candidate not
viable due to substitution failure' note we may produce.

To keep the note small (since the 'overload resolution failed' diagnostics are
often already very verbose), the text of the SFINAE diagnostic is included as
part of the text of the note, and any notes which were attached to it are
discarded.

There happened to be spare space in OverloadCandidate into which a
PartialDiagnosticAt could be squeezed, and this patch goes to lengths to avoid
unnecessary PartialDiagnostic copies, resulting in no slowdown that I could
measure. (Removal in passing of some PartialDiagnostic copies has resulted in a
slightly smaller clang binary overall.) Even on a torture test, I was unable to
measure a memory increase of above 0.2%.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156297 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-07 09:03:25 +00:00
David Blaikie d8a1361ab4 Fix test cases broken by 155936.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155948 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 21:29:03 +00:00
Eli Friedman 9b94cd1b25 Add a missing ExpressionEvaluationContext for template default arguments. Fixes PR12581.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155670 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-26 22:43:24 +00:00
Argyrios Kyrtzidis ad579916bc When resolving default template arguments, it should be done in the declaration context
of the template what we are going to instantiate.

Fixes various crashes of rdar://11242625 & http://llvm.org/PR11421.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155576 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-25 18:39:17 +00:00
Richard Smith 6e21b16ab2 PR12585: When processing a friend template inside a class template, don't
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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155303 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-22 02:13:50 +00:00
Richard Smith 227e9f6f08 Fix test failure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155271 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-21 01:51:32 +00:00
Richard Smith 71c598fc05 When declaring a template, check that the context doesn't already contain a
declaration of the same name. r155187 caused us to miss this if the prior
declaration did not declare a type.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155269 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-21 01:27:54 +00:00
Richard Smith c93e014cd4 Replace r155185 with a better fix, which also addresses PR12557. When looking
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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155187 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-20 07:12:26 +00:00
Richard Smith b2f245e77d Fix a bug which creduce found reducing PR12585.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155185 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-20 05:42:36 +00:00
Patrick Beard eb382ec150 Implements boxed expressions for Objective-C. <rdar://problem/10194391>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155082 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-19 00:25:12 +00:00
Richard Smith 13bffc532b PR 12586: Fix assert while running libc++ testsuite: deal with exception
specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155076 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-19 00:08:28 +00:00
Richard Smith 87162c2e52 PR12569: Instantiate exception specifications of explicit instantiations
and explicit specializations of function templates appropriately.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154956 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-17 22:30:01 +00:00
Richard Smith e6975e9b09 Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it.
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.

When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.

Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.

Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.

This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154886 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-17 00:58:00 +00:00
David Blaikie e31b8fb25b Enable warn_impcast_literal_float_to_integer by default.
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.

The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.

It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154068 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-05 00:16:44 +00:00
Richard Smith 0f6931a2c2 PR12438: Profile a reference to a type template parameter by depth and index,
not by canonical decl. This only matters for sizeof...(Pack) expressions; in
all other cases, we'd profile it as a type instead.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153884 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-02 18:53:24 +00:00
Douglas Gregor 8b0fa5241a If we encounter a friend class template for which we cannot resolve
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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153752 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-30 16:20:47 +00:00
Richard Smith 564f4c5664 During the instantiation of a class template specialization, that
specialization is known to be incomplete. If we're asked to try to
complete it, don't attempt to instantiate it again -- that can lead
to stack overflow, and to rejects-valids if the class being incomplete
is not an error.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153236 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-22 03:35:28 +00:00
Douglas Gregor 957ff27311 Replace a FIXME with a diagnostic when we can't resolve the
nested-name-specifier for a class template declaration. Fixes PR12291.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153006 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-18 00:15:42 +00:00
Richard Smith 69730c115c Fix parsing of type-specifier-seq's. Types are syntactically allowed to be
defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152549 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-12 07:56:15 +00:00
Eli Friedman 4a90e1a8a2 Correct test from r152189.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152191 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-07 01:13:38 +00:00
Eli Friedman 9e9c454b12 Make sure we consistently canonicalize types when canonicalizing TemplateTemplateParmDecls. PR12179.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152189 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-07 01:09:33 +00:00
Richard Smith 16581335fc Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151881 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-02 04:14:40 +00:00
Eli Friedman 72b8b1ef9f A couple minor bug-fixes for template instantiation for expressions which are sometimes potentially evaluated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151707 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-29 04:03:55 +00:00
Eli Friedman a2d7dfab30 Shift Microsoft enum extensions from -fms-extensions to -fms-compatibility, so -fms-extensions doesn't affect enum semantics in incompatible ways. <rdar://problem/10657186>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150663 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16 05:20:44 +00:00
Richard Smith 37ce0104b1 If a static data member of a class template which could be used in a constant
expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150560 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-15 02:42:50 +00:00
Richard Smith 57b9c4e9d8 If a constexpr function template specialization is referenced, and then the
template is defined, and then the specialization is referenced again, don't
forget to instantiate the template on the second reference. Use the source
location of the first reference as the point of instantiation, though.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150518 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-14 22:25:15 +00:00