Commit Graph

1003 Commits

Author SHA1 Message Date
Erich Keane af0795b906 Fix template parameter default args missed if redecled
This bug was found via self-build on lld, and worked around
here: https://reviews.llvm.org/rL316180

The issue is that the 'using' causes the lookup to pick up the
first decl. However, when setting inherited default parameters,
we only update 'forward', not 'backward'. SO, only the newest param
list has all the information about the default arguments.

This patch ensures that the list of parameters we look through checks
the newest decl's template parameter list so it doesn't miss a default.

Differential Revision: https://reviews.llvm.org/D39127

llvm-svn: 316405
2017-10-24 01:39:56 +00:00
Faisal Vali 81b756e6a3 [C++17] Fix PR34970 - tweak overload resolution for class template deduction-guides in line with WG21's p0620r0.
In order to identify the copy deduction candidate, I considered two approaches:
  - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution.
  - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides

After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union.

Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper.  Concordant with that, I made sure the copy deduction candidate is always added.


References:
See https://bugs.llvm.org/show_bug.cgi?id=34970 
See http://wg21.link/p0620r0

llvm-svn: 316292
2017-10-22 14:45:08 +00:00
Richard Smith becb92dec8 [Modules TS] Module ownership semantics for redeclarations.
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.

This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.

llvm-svn: 315379
2017-10-10 22:33:17 +00:00
Eric Liu f01516db8d Revert "[Modules TS] Module ownership semantics for redeclarations."
This reverts commit r315251. See the original commit thread for reason.

llvm-svn: 315309
2017-10-10 13:09:40 +00:00
Richard Smith b87720b77a [Modules TS] Module ownership semantics for redeclarations.
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.

llvm-svn: 315251
2017-10-09 23:42:09 +00:00
Benjamin Kramer c24fb0718d Remove unused variables. No functionality change.
llvm-svn: 315196
2017-10-08 21:23:02 +00:00
Andrew Gozillon 572bbb0754 Dependent Address Space Support
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute. 
The main goal is to add further flexibility to the attribute and allow 
for it to be used easily with templates.

The main additions are a new type (DependentAddressSpaceType) alongside 
its TypeLoc and its mangling. As well as the logic required to support 
dependent address spaces which mainly resides in TreeTransform.h and 
SemaType.cpp.

llvm-svn: 314649
2017-10-02 06:25:51 +00:00
Douglas Gregor 672281a511 Diagnostic specific failed condition in a static_assert.
When a static_assert fails, dig out a specific condition to diagnose,
using the same logic that we use to find the enable_if condition to
diagnose.

llvm-svn: 313315
2017-09-14 23:38:42 +00:00
Faisal Vali f241b0dcd6 [NFC] Remove a cstyle cast and replace some uses of Decl with NamedDecl during the processing of TemplateParameterLists.
llvm-svn: 311788
2017-08-25 18:24:20 +00:00
Reid Kleckner cd016d8dc6 [MS] Don't statically initialize dllimport member function pointers
Summary:
r306137 made dllimport pointers to member functions non-constant. This
is correct because a load must be executed to resolve any dllimported
data. However, r306137 did not account for the use of dllimport member
function pointers used as template arguments.

This change re-lands r306137 with a template instantiation fix.

This fixes PR33570.

Reviewers: rnk, majnemer

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D34714

llvm-svn: 307446
2017-07-07 22:04:29 +00:00
Douglas Gregor c0fe1f211a Fix test case in pre-C++11 mode; address Aaron Ballman's code review.
llvm-svn: 307202
2017-07-05 21:12:37 +00:00
Douglas Gregor bb33f57045 Cope with Range-v3's CONCEPT_REQUIRES idiom
llvm-svn: 307197
2017-07-05 20:20:15 +00:00
Douglas Gregor 00fa10b43f Customize the SFINAE diagnostics for enable_if to provide the failed condition.
When enable_if disables a particular overload resolution candidate,
rummage through the enable_if condition to find the specific condition
that caused the failure. For example, if we have something like:

    template<
      typename Iter,
      typename = std::enable_if_t<Random_access_iterator<Iter> &&
                                  Comparable<Iterator_value_type<Iter>>>>
    void mysort(Iter first, Iter last) {}

and we call "mysort" with "std::list<int>" iterators, we'll get a
diagnostic saying that the "Random_access_iterator<Iter>" requirement
failed. If we call "mysort" with
"std::vector<something_not_comparable>", we'll get a diagnostic saying
that the "Comparable<...>" requirement failed.

llvm-svn: 307196
2017-07-05 20:20:14 +00:00
Akira Hatanaka 12ddceecde [Sema] Fix a crash-on-invalid when a template parameter list has a class
definition or non-reference class type.

The crash occurs when there is a template parameter list in a class that
is missing the closing angle bracket followed by a definition of a
struct. For example:

class C0 {
public:
  template<typename T, typename T1 = T // missing closing angle bracket
  struct S0 {};

  C0() : m(new S0<int>) {}
  S0<int> *m;
};

This happens because the parsed struct is added to the scope of the
enclosing class without having its access specifier set, which results
in an assertion failure in SemaAccess.cpp later.

This commit fixes the crash by adding the parsed struct to the enclosing
file scope and marking structs as invalid if they are defined in
template parameter lists.

rdar://problem/31783961
rdar://problem/19570630

Differential Revision: https://reviews.llvm.org/D33606

llvm-svn: 306317
2017-06-26 18:46:12 +00:00
Galina Kistanova 1d36e833e1 Added llvm_unreachable to make sure the switch is always exhaustive.
llvm-svn: 304997
2017-06-08 18:20:32 +00:00
John McCall 27c11dd57e When determining the target function of an explicit instantiation, make
sure that non-template functions don't end up in the candidate set.

Fixes PR14211.

Patch by Don Hinton!

llvm-svn: 304951
2017-06-07 23:00:05 +00:00
Galina Kistanova 3779cb3c14 Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.
llvm-svn: 304870
2017-06-07 06:25:05 +00:00
Richard Smith 54f0440c1f [modules] Switch from inferring owning modules based on source location to
inferring based on the current module at the point of creation.

This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.

There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.

llvm-svn: 303322
2017-05-18 02:29:20 +00:00
Richard Smith 858e0e0a42 Remove unnecessary mapping from SourceLocation to Module.
When we parse a redefinition of an entity for which we have a hidden existing
declaration, make it visible in the current module instead of mapping the
current source location to its containing module.

llvm-svn: 302842
2017-05-11 23:11:16 +00:00
Richard Smith 52f8d19ced Improve diagnosis of unknown template name.
When an undeclared identifier in a context that requires a type is followed by
'<', only look for type templates when typo-correcting, tweak the diagnostic
text to say that a template name (not a type name) was undeclared, and parse
the template arguments when recovering from the error.

llvm-svn: 302732
2017-05-10 21:32:16 +00:00
Richard Smith 42bc73a3f1 When we see a '<' operator, check whether it's a probable typo for a template-id.
The heuristic that we use here is:
 * the left-hand side must be a simple identifier or a class member access
 * the right-hand side must be '<' followed by either a '>' or by a type-id that
   cannot be an expression (in particular, not followed by '(' or '{')
 * there is a '>' token matching the '<' token

The second condition guarantees the expression would otherwise be ill-formed.

If we're confident that the user intended the name before the '<' to be
interpreted as a template, diagnose the fact that we didn't interpret it
that way, rather than diagnosing that the template arguments are not valid
expressions.

llvm-svn: 302615
2017-05-10 02:30:28 +00:00
Richard Smith 77e9e84a8e Don't mark a member as a member specialization until we know we're keeping the specialization.
This improves our behavior in a few ways:

 * We now guarantee that if a member is marked as being a member
   specialization, there will actually be a member specialization declaration
   somewhere on its redeclaration chain. This fixes a crash in modules builds
   where we would try to check that there was a visible declaration of the
   member specialization and be surprised to not find any declaration of it at
   all.

 * We don't set the source location of the in-class declaration of the member
   specialization to the out-of-line declaration's location until we have
   actually finished merging them. This fixes some very silly looking
   diagnostics, where we'd point a "previous declaration is here" note at the
   same declaration we're complaining about. Ideally we wouldn't mess with the
   prior declaration's location at all, but too much code assumes that the
   first declaration of an entity is a reasonable thing to use as an indication
   of where it was declared, and that's not really true for a member
   specialization unless we fake it like this.

llvm-svn: 302596
2017-05-09 23:02:10 +00:00
Richard Smith 479ba8ee0e PR32673: Don't wrap parameter packs in SubstTemplateTypeParmPackType nodes when forming implicit deduction guides.
Doing so thwarts template type deduction. Instead, substitute the pack directly
by picking "slice 0" of the resulting expansion.

llvm-svn: 300805
2017-04-20 01:15:31 +00:00
Richard Smith 1389418e18 PR32185: Revert r291512 and add a testcase for PR32185.
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)

The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.

llvm-svn: 300262
2017-04-13 21:37:24 +00:00
Faisal Vali d143a0c2de [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum
- also replace direct equality checks against the ConstantEvaluated enumerator  with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.

- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.

llvm-svn: 299316
2017-04-01 21:30:49 +00:00
Eric Christopher 0d2c56a5c0 Fix typo, defind -> defined.
llvm-svn: 299148
2017-03-31 01:45:39 +00:00
Erich Keane a32910da1a Correct class-template deprecation behavior-REDUX
Correct class-template deprecation behavior

Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;

This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.

Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.

Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410

Differential Revision: https://reviews.llvm.org/D31245

llvm-svn: 298634
2017-03-23 18:51:54 +00:00
Martin Bohme 926572303e Revert "Correct class-template deprecation behavior"
This reverts commit r298410 (which produces incorrect warnings, see
comments on https://reviews.llvm.org/rL298410).

llvm-svn: 298504
2017-03-22 13:34:37 +00:00
Erich Keane 8a8f5f0f00 Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;

This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.

Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.

Differential Revision: https://reviews.llvm.org/D27486

llvm-svn: 298410
2017-03-21 17:49:17 +00:00
Richard Smith 4ae5ec8268 Improve support for 'decltype(auto)' in template template parameter matching.
A 'decltype(auto)' parameter can match any other kind of non-type template
parameter, so should be usable in place of any other parameter in a template
template argument. The standard is sadly extremely unclear on how this is
supposed to work, but this seems like the obviously-correct result.

It's less clear whether an 'auto' parameter should be able to match
'decltype(auto)', since the former cannot be used if the latter turns out to be
used for a reference type, but if we disallow that then consistency suggests we
should also disallow 'auto' matching 'T' for the same reason, defeating
intended use cases of the feature.

llvm-svn: 295866
2017-02-22 20:01:55 +00:00
Richard Smith b4f9625a7b PR32010: Fix template argument depth mixup when forming implicit constructor
template deduction guides for class template argument deduction.

Ensure that we have a local instantiation scope for tracking the instantiated
parameters. Additionally, unusually, we're substituting at depth 1 and leaving
depth 0 alone; make sure that we don't reduce template parameter depth by 2 for
inner parameters in the process. (This is probably also broken for alias
templates in the case where they're expanded within a dependent context, but
this patch doesn't fix that.)

llvm-svn: 295696
2017-02-21 06:30:38 +00:00
Richard Smith 51ec0cf4aa Factor out function to determine whether we're performing a template
instantiation.

In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).

llvm-svn: 295686
2017-02-21 01:17:38 +00:00
Richard Smith bc491203c7 Add an explicit derived class of FunctionDecl to model deduction guides rather
than just treating them as FunctionDecls with a funny name.

No functionality change intended.

llvm-svn: 295491
2017-02-17 20:05:37 +00:00
Richard Smith efa919ab07 Properly set up the DeclContext for parameters of implicit deduction guides;
this is needed for deferred instantiation of default arguments.

llvm-svn: 295379
2017-02-16 21:29:21 +00:00
Richard Smith 4e05eaa9e8 [c++1z] Diagnose non-deducible template parameters in deduction guide templates, per [temp.param]p11.
llvm-svn: 295264
2017-02-16 00:36:47 +00:00
Richard Smith c27b3d7623 Canonicalize implicit deduction guide parameter types when forming a deduction
guide from a constructor.

The purpose of this change is to avoid triggering instantiation of the class
when substituting back into the deduction guide if it uses a typedef member.
We will still instantiate the class if the constructor (explicitly or
implicitly, directly or indirectly) uses the current instantiation in a way
that we can't canonicalize out, but that seems unavoidable.

llvm-svn: 295016
2017-02-14 01:49:59 +00:00
Richard Smith 3291877656 [c++1z] Synthesize implicit deduction guides from constructors on demand. Rank
such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.

We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
   without losing default arguments or a varargs ellipsis (which the standard
   wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
   (which will only ever work if T has default arguments for all non-pack
   template parameters).
3) If the class template declares nothing that looks like a copy or move
   constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.

llvm-svn: 295007
2017-02-14 00:25:28 +00:00
Richard Smith 278890f85b [c++1z] Enforce restriction that deduction guide is declared in the same scope as its template.
llvm-svn: 294778
2017-02-10 20:39:58 +00:00
Hubert Tong 5a8ec4e287 [Concepts] Class template associated constraints
Summary:
This adds associated constraints as a property of class templates.
An error is produced if redeclarations are not similarly constrained.

Reviewers: rsmith, faisalv, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits, nwilson

Differential Revision: https://reviews.llvm.org/D25674

llvm-svn: 294697
2017-02-10 02:46:19 +00:00
Richard Smith 19a311a483 Disallow explicit instantiation and explicit specialization for deduction guides.
llvm-svn: 294641
2017-02-09 22:47:51 +00:00
Richard Smith f445f196ae Rename IsExplicitSpecialization -> IsMemberSpecialization when we're talking
about member specializations to avoid ambiguous and confusing terminology.

llvm-svn: 294622
2017-02-09 21:04:43 +00:00
Richard Smith 3411fbff0b Repoint 'missing typename' diagnostic to the location where 'typename' should be added.
llvm-svn: 293817
2017-02-01 21:41:18 +00:00
Richard Smith 62559bd7ce Fix hole in our enforcement of rule requiring 'typename' prior to a dependent
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
2017-02-01 21:36:38 +00:00
Richard Smith ee57984c11 Towards P0091R3: parsing support for class template argument deduction in typename-specifiers.
This reinstates r293455, reverted in r293455, with a fix for cv-qualifier
handling on dependent typename-specifiers.

llvm-svn: 293544
2017-01-30 20:39:26 +00:00
Sam McCall 4f53b51fe7 Revert r293455, which breaks v8 with a spurious error. Testcase added.
Summary: Revert r293455, which breaks v8 with a spurious error. Testcase added.

Reviewers: klimek

Subscribers: cfe-commits, rsmith

Differential Revision: https://reviews.llvm.org/D29271

llvm-svn: 293473
2017-01-30 10:44:11 +00:00
Richard Smith c95726ea39 Towards P0091R3: parsing support for class template argument deduction in typename-specifiers.
llvm-svn: 293455
2017-01-30 04:38:28 +00:00
Richard Smith fc6fca1cab When converting a template argument representing &array to an expression for a
pointer typed template parameter, form &array rather than an array-to-pointer
decay on array.

llvm-svn: 293350
2017-01-28 00:38:35 +00:00
Richard Smith 600b5261c4 PR0091R3: Implement parsing support for using templates as types.
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.

We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.

llvm-svn: 293207
2017-01-26 20:40:47 +00:00
Richard Smith fd3dae024f Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).
Diagnose the case when a dependent template name instantiates to an
injected-class-name outside a nested-name-specifier.

llvm-svn: 292545
2017-01-20 00:20:39 +00:00
Richard Smith 74f02347ca PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).

As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).

When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.

llvm-svn: 292518
2017-01-19 21:00:13 +00:00