Commit Graph

869 Commits

Author SHA1 Message Date
Artem Belevich 67d22c8a84 Revert "[CUDA] Check initializers of instantiated template variables."
This (temporarily) reverts commit r329127 due to the problems
it exposed in TensorFlow.

llvm-svn: 329229
2018-04-04 20:48:42 +00:00
Artem Belevich d9189d1e76 [CUDA] Check initializers of instantiated template variables.
We were already performing checks on non-template variables,
but the checks on templated ones were missing.

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

llvm-svn: 329127
2018-04-03 22:41:06 +00:00
George Karpenkov ec38cf7aed [ast] Do not auto-initialize Objective-C for-loop variables in Objective-C++ in templatized code under ARC
The AST for the fragment

```
@interface I
@end

template <typename>
void decode(I *p) {
  for (I *k in p) {}
}

void decode(I *p) {
  decode<int>(p);
}
```

differs heavily when templatized and non-templatized:

```
|-FunctionTemplateDecl 0x7fbfe0863940 <line:4:1, line:7:1> line:5:6 decode
| |-TemplateTypeParmDecl 0x7fbfe0863690 <line:4:11> col:11 typename depth 0 index 0
| |-FunctionDecl 0x7fbfe08638a0 <line:5:1, line:7:1> line:5:6 decode 'void (I *__strong)'
| | |-ParmVarDecl 0x7fbfe08637a0 <col:13, col:16> col:16 referenced p 'I *__strong'
| | `-CompoundStmt 0x7fbfe0863b88 <col:19, line:7:1>
| |   `-ObjCForCollectionStmt 0x7fbfe0863b50 <line:6:3, col:20>
| |     |-DeclStmt 0x7fbfe0863a50 <col:8, col:13>
| |     | `-VarDecl 0x7fbfe08639f0 <col:8, col:11> col:11 k 'I *const __strong'
| |     |-ImplicitCastExpr 0x7fbfe0863a90 <col:16> 'I *' <LValueToRValue>
| |     | `-DeclRefExpr 0x7fbfe0863a68 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe08637a0 'p' 'I *__strong'
| |     `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
| `-FunctionDecl 0x7fbfe0863f80 <line:5:1, line:7:1> line:5:6 used decode 'void (I *__strong)'
|   |-TemplateArgument type 'int'
|   |-ParmVarDecl 0x7fbfe0863ef8 <col:13, col:16> col:16 used p 'I *__strong'
|   `-CompoundStmt 0x7fbfe0890cf0 <col:19, line:7:1>
|     `-ObjCForCollectionStmt 0x7fbfe0890cc8 <line:6:3, col:20>
|       |-DeclStmt 0x7fbfe0890c70 <col:8, col:13>
|       | `-VarDecl 0x7fbfe0890c00 <col:8, col:11> col:11 k 'I *__strong' callinit
|       |   `-ImplicitValueInitExpr 0x7fbfe0890c60 <<invalid sloc>> 'I *__strong'
|       |-ImplicitCastExpr 0x7fbfe0890cb0 <col:16> 'I *' <LValueToRValue>
|       | `-DeclRefExpr 0x7fbfe0890c88 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe0863ef8 'p' 'I *__strong'
|       `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
```

Note how in the instantiated version ImplicitValueInitExpr unexpectedly appears.

While objects are auto-initialized under ARC, it does not make sense to
have an initializer for a for-loop variable, and it makes even less
sense to have such a different AST for instantiated and non-instantiated
version.

Digging deeper, I have found that there are two separate Sema* files for
dealing with templates and for dealing with non-templatized code.
In a non-templatized version, an initialization was performed only for
variables which are not loop variables for an Objective-C loop and not
variables for a C++ for-in loop:

```
  if (FRI && (Tok.is(tok::colon) || isTokIdentifier_in())) {
    bool IsForRangeLoop = false;
    if (TryConsumeToken(tok::colon, FRI->ColonLoc)) {
      IsForRangeLoop = true;
      if (Tok.is(tok::l_brace))
        FRI->RangeExpr = ParseBraceInitializer();
      else
        FRI->RangeExpr = ParseExpression();
    }

    Decl *ThisDecl = Actions.ActOnDeclarator(getCurScope(), D);
    if (IsForRangeLoop)
      Actions.ActOnCXXForRangeDecl(ThisDecl);
    Actions.FinalizeDeclaration(ThisDecl);
    D.complete(ThisDecl);
    return Actions.FinalizeDeclaratorGroup(getCurScope(), DS, ThisDecl);
  }

  SmallVector<Decl *, 8> DeclsInGroup;
  Decl *FirstDecl = ParseDeclarationAfterDeclaratorAndAttributes(
      D, ParsedTemplateInfo(), FRI);
```

However the code in SemaTemplateInstantiateDecl was inconsistent,
guarding only against C++ for-in loops.

rdar://38391075

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

llvm-svn: 328749
2018-03-29 00:56:24 +00:00
Reid Kleckner 24bd88c0b0 [MS] Fix late-parsed template infinite loop in eager instantiation
Summary:
This fixes PR33561 and PR34185.

Don't store pending template instantiations for late-parsed templates in
the normal PendingInstantiations queue. Instead, use a separate list
that will only be parsed and instantiated at end of TU when late
template parsing actually works and doesn't infinite loop.

Reviewers: rsmith, thakis, hans

Subscribers: cfe-commits

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

llvm-svn: 328567
2018-03-26 18:22:47 +00:00
Jordan Rose 1e879d8be6 Sink PrettyDeclStackTrace down to the AST library
...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.

llvm-svn: 328276
2018-03-23 00:07:18 +00:00
George Burgess IV 18b28a86c1 Properly construct `inline` members without initializers
Digging through commit logs, it appears the checks in this block predate
`inline` class variables. With them, we fail to emit dynamic
initializers for members that don't have an explicit initializer, and we
won't go out of our way to instantiate the class denoted by
`Var->getType()`.

Fixes PR35599.

llvm-svn: 327945
2018-03-20 03:27:44 +00:00
Richard Smith c660c8f5d2 Implement C++ DR727, which permits explicit specializations at class scope.
More generally, this permits a template to be specialized in any scope in which
it could be defined, so this also supersedes DR44 and DR374 (the latter of
which we previously only implemented in C++11 mode onwards due to unclarity as
to whether it was a DR).

llvm-svn: 327705
2018-03-16 13:36:56 +00:00
Richard Trieu 09c163bb6b Refactoring code around move/copy initialization. NFC.
Use an enum parameter instead of a bool for more control on how the copy elision
functions work.  Extract the move initialization code from the move or copy
initialization block.

Patch by: Arthur O'Dwyer

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

llvm-svn: 327598
2018-03-15 03:00:55 +00:00
Ilya Biryukov 0ee4a08c00 [Sema] Pop function scope when instantiating a func with skipped body
Summary:
By calling ActOnFinishFunctionBody(). Previously we were only calling
ActOnSkippedFunctionBody, which didn't pop the function scope.
This causes a crash when running on our internal code. No test-case,
though, since I couldn't come up with a small example in reasonable
time.

The bug was introduced in r321174.

Reviewers: bkramer, sammccall, sepavloff, aaron.ballman

Reviewed By: sammccall, aaron.ballman

Subscribers: aaron.ballman, cfe-commits

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

llvm-svn: 327504
2018-03-14 13:18:30 +00:00
Joel E. Denny 8150810556 Reland "[Attr] Fix parameter indexing for several attributes"
Relands r326602 (reverted in r326862) with new test and fix for
PR36620.

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

llvm-svn: 327405
2018-03-13 14:51:22 +00:00
Richard Smith 5d3310208a When substituting previously-checked template arguments into a template
template parameter that is an expanded parameter pack, only substitute into the
current slice, not the entire pack.

This reduces the checking of N template template arguments for an expanded
parameter pack containing N parameters from quadratic time to linear time in
the length of the pack. This is important because one (and possibly the only?)
general technique for splitting a template parameter pack in linear time
depends on doing this.

llvm-svn: 326973
2018-03-08 01:07:33 +00:00
Nico Weber bbf648253d Revert r326602, it caused PR36620.
llvm-svn: 326862
2018-03-07 02:22:41 +00:00
Joel E. Denny 4925445958 [Attr] Fix parameter indexing for several attributes
The patch fixes a number of bugs related to parameter indexing in
attributes:

* Parameter indices in some attributes (argument_with_type_tag,
  pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
  and ownership_returns) are specified in source as one-origin
  including any C++ implicit this parameter, were stored as
  zero-origin excluding any this parameter, and were erroneously
  printing (-ast-print) and confusingly dumping (-ast-dump) as the
  stored values.

* For alloc_size, the C++ implicit this parameter was not subtracted
  correctly in Sema, leading to assert failures or to silent failures
  of __builtin_object_size to compute a value.

* For argument_with_type_tag, pointer_with_type_tag, and
  ownership_returns, the C++ implicit this parameter was not added
  back to parameter indices in some diagnostics.

This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes.  ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed.  Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*].  This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument.  The only exception is xray_log_args's
argument, which is encoded as a count not an index.

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

llvm-svn: 326602
2018-03-02 19:03:22 +00:00
Serge Pavlov e6e534ca22 Function definition may have uninstantiated body
Current implementation of `FunctionDecl::isDefined` does not take into
account redeclarations that do not have bodies, but the bodies can be
instantiated from corresponding templated definition. This behavior does
not allow to detect function redefinition in the cases where friend
functions is defined in class templates. For instance, the code:
```
    template<typename T> struct X { friend void f() {} };
    X<int> xi;
    void f() {}
```
compiles successfully but must fail due to redefinition of `f`. The
declaration of the friend `f` is created when the containing template
`X` is instantiated, but it does not have a body as per 14.5.4p4
because `f` is not odr-used.

With this change the function `Sema::CheckForFunctionRedefinition`
considers functions with uninstantiated bodies as definitions.

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

llvm-svn: 326419
2018-03-01 07:04:11 +00:00
George Burgess IV 00f70bd933 Remove redundant casts. NFC
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.

Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).

I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.

llvm-svn: 326416
2018-03-01 05:43:23 +00:00
Reid Kleckner b0a17edff7 [Sema] Don't mark plain MS enums as fixed
Summary:
This fixes a flaw in our AST: PR27098

MSVC always gives plain enums the underlying type 'int'. Clang does this
as well, but we claim the enum is "fixed", as if the user actually wrote
': int'. It means we end up emitting spurious -Wsign-compare warnings on
code like this:

  enum Vals { E1, E2, E3 };
  bool f(unsigned v1, Vals v2) {
    return v1 == v2;
  }

We think 'v2' can take on negative values because we think 'Vals' is
fixed. This fixes that.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 324913
2018-02-12 17:37:06 +00:00
Gabor Horvath 207e7b1fa1 [Templight] Template Instantiation Observer
This patch adds a base-class called TemplateInstantiationObserver which gets
notified whenever a template instantiation is entered or exited during
semantic analysis. This is a base class used to implement the template
profiling and debugging tool called
Templight (https://github.com/mikael-s-persson/templight).

The patch also makes a few more changes:

* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h).
* CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function).
* TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers.
* Notifications to the template-inst observer are added at the key places where templates are instantiated.

Patch by: Abel Sinkovics!

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

llvm-svn: 324808
2018-02-10 14:04:45 +00:00
Richard Smith 93ee9caaed In C++17, when instantiating an out-of-line definition of an inline static data
member, don't forget to instantiate the initializer too.

llvm-svn: 322236
2018-01-10 23:08:26 +00:00
Richard Smith 33bddbd64b Make attribute instantiation instantiate all attributes, not just the first of
each kind.

Attribute instantiation would previously default to instantiating each kind of
attribute only once. This was overridden by a flag whose intended purpose was
to permit attributes from a prior declaration to be inherited onto a new
declaration even if that new declaration had its own copy of the attribute.
This is the wrong behavior: when instantiating attributes from a template, we
should always instantiate all the attributes that were written on that
template.

This patch renames the flag in the Attr class (and TableGen sources) to more
clearly identify what it's actually for, and removes the usage of the flag from
template instantiation. I also removed the flag from AlignedAttr, which was
only added to work around the incorrect suppression of duplicate attribute
instantiation.

llvm-svn: 321834
2018-01-04 23:42:29 +00:00
Richard Smith 50e291eaf2 Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.
Previously, we would:
 * compute the type of the conversion function and static invoker as a
   side-effect of template argument deduction for a conversion
 * re-compute the type as part of deduced return type deduction when building
   the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.

llvm-svn: 321683
2018-01-02 23:52:42 +00:00
Nick Lewycky 2adab1bc56 Suppress undefined-template warnings when the pattern is declared in a system header.
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.

llvm-svn: 321665
2018-01-02 19:10:12 +00:00
Ilya Biryukov 95f0d3286b [Frontend] Correctly handle instantiating ctors with skipped bodies
Summary:
Previsouly clang tried instantiating member initializers even if ctor
body was skipped, this caused spurious errors (see the test).

Reviewers: sepavloff, klimek

Reviewed By: sepavloff

Subscribers: cfe-commits

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

llvm-svn: 321520
2017-12-28 13:05:46 +00:00
Richard Smith 4fa14515ac When instantiating a deduction guide, transform its name.
Otherwise it will serve as a deduction guide for the wrong class template.

llvm-svn: 321297
2017-12-21 19:43:39 +00:00
Ilya Biryukov a27eca283b [Frontend] Handle skipped bodies in template instantiations
Summary:
- Fixed an assert in Sema::InstantiateFunctionDefinition and added
  support for instantiating a function template with skipped body.
- Properly call setHasSkippedBody for FunctionTemplateDecl passed to
  Sema::ActOnSkippedFunctionBody.

Reviewers: sepavloff, bkramer

Reviewed By: sepavloff

Subscribers: klimek, cfe-commits

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

llvm-svn: 321174
2017-12-20 14:32:38 +00:00
Adrian Prantl f3b3ccda59 Silence a bunch of implicit fallthrough warnings
llvm-svn: 321115
2017-12-19 22:06:11 +00:00
Richard Smith 891fc7f37a Generalize "static data member instantiated" notification to cover variable templates too.
While here, split the "point of instantiation changed" notification out from
it; these two really are orthogonal changes.

llvm-svn: 319727
2017-12-05 01:31:47 +00:00
Richard Smith 435e647a41 PR35456: Track definedness of variable template specializations separately from
whether they have an initializer.

We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.

llvm-svn: 319605
2017-12-02 02:48:42 +00:00
Richard Smith cb18957da0 Never try to instantiate a deduction guide's "definition". Fixes bogus warning when there inevitably isn't one.
llvm-svn: 316820
2017-10-28 01:15:00 +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 4309b66710 Don't suppress instantiation of definitions for variables subject to explicit
instantiation declarations if they are usable from constant expressions.

We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.

llvm-svn: 316136
2017-10-18 22:45:01 +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
Richard Smith 81df9eb0f2 PR33839: Fix -Wunused handling for structured binding declarations.
We warn about a structured binding declaration being unused only if none of its
bindings are used.

llvm-svn: 314733
2017-10-02 22:43:36 +00:00
Richard Smith c95d2c5dda Give external linkage and mangling to lambdas inside inline variables and variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33

This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds
enumeration value' ubsan error in that change.

llvm-svn: 313955
2017-09-22 04:25:05 +00:00
Vitaly Buka 17def21749 Revert "Give external linkage and mangling to lambdas inside inline variables and variable templates."
To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind'

This reverts commit r313827.

llvm-svn: 313856
2017-09-21 02:51:56 +00:00
Richard Smith fb130c6084 Give external linkage and mangling to lambdas inside inline variables and variable templates.
This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33

llvm-svn: 313827
2017-09-20 22:17:55 +00:00
Alexey Bataev 070f43aee7 [OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in
move constructor.

Previously user-defined reduction initializer was considered as an
assignment expression, not as initializer. Fixed this by treating the
initializer expression as an initializer.

llvm-svn: 312638
2017-09-06 14:49:58 +00:00
Richard Smith 6c716116df PR34163: Don't cache an incorrect key function for a class if queried between
the class becoming complete and its inline methods being parsed.

This replaces the hack of using the "late parsed template" flag to track member
functions with bodies we've not parsed yet; instead we now use the "will have
body" flag, which carries the desired implication that the function declaration
*is* a definition, and that we've just not parsed its body yet.

llvm-svn: 310776
2017-08-12 01:46:03 +00:00
Richard Smith 90dc525472 PR33552: Distinguish between declarations that are owned by no module and
declarations that are owned but unconditionally visible.

This allows us to set declarations as visible even if they have a local owning
module, without losing information. In turn, that means that our Objective-C
support can keep on incorrectly assuming the "hidden" bit on the declaration is
the whole story with regard to name visibility. This will also be useful once
we support the C++ Modules TS export semantics.

Objective-C name visibility is still incorrect in any case where the "hidden"
bit is not the complete story: for instance, in Objective-C++ the set of
visible categories will be wrong during template instantiation, and with local
submodule visibility enabled it will be wrong when building modules. Fixing that
will require a major overhaul of how visibility is handled for Objective-C (and
particularly for categories).

llvm-svn: 306075
2017-06-23 01:04:34 +00:00
Richard Smith 05a21351d6 PR33002: When we instantiate the definition of a static data member, we might
have attached an initializer to the in-class declaration. If so, include the
initializer in the update record for the instantiation.

llvm-svn: 306065
2017-06-22 22:18:46 +00:00
Serge Pavlov 25dbe1a16e Function with unparsed body is a definition
While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
    template<typename T> struct Somewhat {
      void internal() const {}
      friend void operator+(int const &, Somewhat<T> const &) {}
    };
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.

To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.

This change fixes PR14785.

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

This is a recommit of 305379, reverted in 305381, with small changes.

llvm-svn: 305903
2017-06-21 12:46:57 +00:00
Sunil Srivastava 15ed292906 Prevent devirtualization of calls to un-instantiated functions.
PR 27895

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

llvm-svn: 305862
2017-06-20 22:08:44 +00:00
Serge Pavlov a4ab1b1c59 Reverted 305379 (Function with unparsed body is a definition)
It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots.

llvm-svn: 305381
2017-06-14 10:57:56 +00:00
Serge Pavlov c73c81be5c Function with unparsed body is a definition
While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
    template<typename T> struct Somewhat {
      void internal() const {}
      friend void operator+(int const &, Somewhat<T> const &) {}
    };
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.

To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.

This change fixes PR14785.

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

llvm-svn: 305379
2017-06-14 10:07:02 +00:00
Richard Smith 4f440e3af5 Weaken restriction in r304862 to allow implicit deduction guides to reference
the injected-class-name of a specialization that uses a partial / explicit
specialization.

llvm-svn: 304957
2017-06-08 01:08:50 +00:00
Richard Smith e6d4b773de Fix a couple of class template argument deduction crashes with libc++'s tuple.
RecursiveASTVisitor was not properly recursing through a
SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we
couldn't always find an unexpanded pack within a pack expansion.

We also have an issue where substitution of deduced template arguments for an
implicit deduction guide creates the "impossible" case of naming a
non-dependent member of the current instantiation, but within a specialization
that is actually instantiated from a different (partial/explicit)
specialization of the template. We resolve this by declaring that constructors
that do so can only be used to deduce specializations of the primary template.
I'm running this past CWG to see if people agree this is the right thing to do.

llvm-svn: 304862
2017-06-07 02:42:27 +00:00
Richard Smith 4f3e3811d1 Rename RAII objects for performing eager instantiation to have names that
describe what they're for, not how they do it, and factor out a bit more
common code into them.

llvm-svn: 303479
2017-05-20 01:36:41 +00:00
Richard Smith f3597653fb When instantiating a friend function template, don't forget to inherit default template arguments from other declarations.
llvm-svn: 302603
2017-05-10 00:01:13 +00:00
Faisal Vali 40fd4cebf8 Fix PR32638 : Make sure we switch Sema's CurContext to the substituted FunctionDecl when instantiating the exception specification.
This fixes the bug: https://bugs.llvm.org/show_bug.cgi?id=32638

  int main()
  {
    [](auto x) noexcept(noexcept(x)) { } (0);
  }

In the above code, prior to this patch, when substituting into the noexcept expression, i.e. transforming the DeclRefExpr that represents 'x' - clang attempts to capture 'x' because Sema's CurContext is still pointing to the pattern FunctionDecl (i.e. the templated-decl set in FinishTemplateArgumentDeduction) which does not match the substituted 'x's DeclContext, which leads to an attempt to capture and an assertion failure.  

We fix this by adjusting Sema's CurContext to point to the substituted FunctionDecl under which the noexcept specifier's argument should be transformed, and so the ParmVarDecl that 'x' refers to has the same declcontext and no capture is attempted. 

I briefly investigated whether the SwitchContext should occur right after VisitMethodDecl creates the new substituted FunctionDecl, instead of only during instantiating the exception specification - but seeing no other code that seemed to rely on that, I decided to leave it just for the duration of the exception specification instantiation.

llvm-svn: 302507
2017-05-09 04:17:15 +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
Erich Keane 623efd8a75 Clang changes for alloc_align attribute
GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to.

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

llvm-svn: 299117
2017-03-30 21:48:55 +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 696e31271b Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation for
using it for other kinds of context (where we currently produce context notes
in a highly ad-hoc manner).

llvm-svn: 295919
2017-02-23 01:43:54 +00:00
Richard Smith 0cd9c0491e Fix lookup through injected-class-names in implicit deduction guides in the
case where the class template has a parameter pack.

Checking of the template arguments expects an "as-written" template argument
list, which in particular does not have any parameter packs. So flatten the
packs into separate arguments before passing them in.

llvm-svn: 295710
2017-02-21 08:42:39 +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 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
Tim Shen b34d0ef2ca [VLA] Handle VLA size expression in a full-expression context.
Summary: Previously the cleanups (e.g. dtor calls) are inserted into the
outer scope (e.g. function body scope), instead of it's own scope. After
the fix, the cleanups are inserted right after getting the size value.

This fixes pr30306.

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 295123
2017-02-14 23:46:37 +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 afe4aa8b2c [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.
llvm-svn: 294693
2017-02-10 02:19:05 +00:00
Akira Hatanaka 59e3b43abc [Sema] Transform a templated name before looking it up in
FindInstantiatedDecl or passing it to RebuildMemberExpr.

This fixes PR30361.

rdar://problem/17341274

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

llvm-svn: 293678
2017-01-31 19:53:32 +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 152bcd2d0d Switch the template specialization kind for a non-defining declaration of a
non-template function instantiated from a friend declaration in a class
template from TSK_ImplicitInstantiation to TSK_Undeclared.

It doesn't make sense for a non-template function to be flagged as being
instantiated from a template; that property really belongs to the entity
as a whole and not an individual declaration of it. There's some history
here:

 * r137934 started marking these functions as instantiations in order to
   work around an issue where we might instantiate a class template while
   we're still parsing its member definitions, and would otherwise fail
   to instantiate the friend definition

 * r177003 fixed the same issue but for friend templates, but did so by
   making the friends claim to be definitions even before we'd parsed
   their actual bodies; this made the r137934 change redundant

 * r293558 worked around a problem caused by the marking of a non-template
   function as a template instantiation in r137934

This change reverts the code changes from r293358 and r137934 and retains
all the tests.

llvm-svn: 293367
2017-01-28 02:56:07 +00:00
Richard Smith cfa5dc4a1d -Wunused-func-template: do not warn on non-template function declarations that
were nonetheless instantiated (particularly, non-template friends declared
within class templates).

llvm-svn: 293358
2017-01-28 01:50:33 +00:00
Vassil Vassilev 352e4412e1 PR31469: Don't add friend template class decls to redecl chain in dependent contexts.
Fixes a crash in modules where the template class decl becomes the most recent
decl in the redeclaration chain and forcing the template instantiator try to
instantiate the friend declaration, rather than the template definition.
    
In practice, A::list<int> produces a TemplateSpecializationType
A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to
subsitute the default argument to allocator<int>.
    
Kudos Richard Smith (D28399).

llvm-svn: 291753
2017-01-12 09:16:26 +00:00
Richard Smith 3beb7c6b5f Remove redundant passing around of a "ContainsAutoType" flag.
This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.

No functionality change intended.

llvm-svn: 291737
2017-01-12 02:27:38 +00:00
George Burgess IV 177399e227 Add the diagnose_if attribute to clang.
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:

```
constexpr int foo(int a)
  __attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
                                      "expensive.", "warning")));

int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```

It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:

```
constexpr int bar(int a) {
  foo(a);
  return 0;
}

constexpr int i = bar(10);
```

We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.

Release notes will appear shortly. :)

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

llvm-svn: 291418
2017-01-09 04:12:14 +00:00
Richard Smith 0ba25a5cef Fix buildbots.
llvm-svn: 291360
2017-01-07 19:58:39 +00:00
Richard Smith 917316fc5d Consistently use a ConstantEvaluated context for expressions in attributes,
except for those with the "attributes are unevaluated contexts" flag.

llvm-svn: 291358
2017-01-07 19:42:26 +00:00
Reid Kleckner 61195e12fc [MS] Instantiate default args during instantiation of exported default ctors
Summary:
Replace some old code that probably pre-dated the change to delay
emission of dllexported code until after the closing brace of the
outermost record type. Only uninstantiated default argument expressions
need to be handled now. It is enough to instantiate default argument
expressions when instantiating dllexported default ctors. This also
fixes some double-diagnostic issues in this area.

Fixes PR31500

Reviewers: rsmith

Subscribers: cfe-commits

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

llvm-svn: 291045
2017-01-05 01:08:22 +00:00
Richard Smith ece4758bf2 Only instantiate members of nested classes in local classes once, rather than once per enclosing class.
llvm-svn: 291034
2017-01-04 23:45:01 +00:00
Richard Smith 15361a21e0 Mark 'auto' as dependent when instantiating the type of a non-type template
parameter. Fixes failed deduction for 'auto' non-type template parameters
nested within templates.

llvm-svn: 290660
2016-12-28 06:27:18 +00:00
Richard Smith 57aae07b4a DR1315: a non-type template argument in a partial specialization is permitted
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
2016-12-28 02:37:25 +00:00
Richard Smith 151c456858 [c++1z] P0195R2: Support pack-expansion of using-declarations.
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.

This is a re-commit of r290080 (reverted in r290092) with a fix for a
use-after-lifetime bug.

llvm-svn: 290203
2016-12-20 21:35:28 +00:00
Daniel Jasper 9949ead55a Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."
This reverts commit r290080 as it leads to many Clang crashes, e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814

llvm-svn: 290092
2016-12-19 10:09:25 +00:00
Richard Smith 22a250cd5d [c++1z] P0195R2: Support pack-expansion of using-declarations.
This change introduces UsingPackDecl as a marker for the set of UsingDecls
produced by pack expansion of a single (unresolved) using declaration. This is
not strictly necessary (we just need to be able to map from the original using
declaration to its expansions somehow), but it's useful to maintain the
invariant that each declaration reference instantiates to refer to one
declaration.

llvm-svn: 290080
2016-12-19 04:08:53 +00:00
Richard Smith d8a9e37558 Fix some interactions between C++11 and C++14 features and using-declarations:
* a dependent non-type using-declaration within a function template can be
   valid, as it can refer to an enumerator, so don't reject it in the template
   definition
 * we can partially substitute into a dependent using-declaration if it appears
   within a (local class in a) generic lambda within a function template, which
   means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl.

llvm-svn: 290071
2016-12-18 21:39:37 +00:00
Malcolm Parsons 57ae857548 [Sema] Set range end of constructors and destructors in template instantiations
Summary:
clang-tidy checks frequently use source ranges of functions.
The source range of constructors and destructors in template instantiations
is currently a single token.
The factory method for constructors and destructors does not allow the
end source location to be specified.
Set end location manually after creating instantiation.

Reviewers: aaron.ballman, rsmith, arphaman

Subscribers: arphaman, cfe-commits

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

llvm-svn: 288025
2016-11-28 11:11:34 +00:00
George Burgess IV 004319554c [Sema] Fix a bug in enable_if condition instantiation.
During template instantiation, we currently fall back to just calling
Sema::SubstExpr for enable_if attributes that aren't value-dependent or
type-dependent. Since Sema::SubstExpr strips off any implicit casts
we've added to an expression, it's possible that this behavior will
leave us with an enable_if condition that's just a DeclRefExpr.
Conditions like that deeply confuse Sema::CheckEnableIf.

llvm-svn: 287187
2016-11-17 01:33:54 +00:00
Faisal Vali 0528a31ddf Fix PR28366: Handle variables from enclosing local scopes more gracefully during constant expression evaluation.
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.


void f(char c) { 
  struct X {
    static constexpr char f() { 
      return c; // error gracefully here as opposed to crashing.
    }
  };
  int I = X::f();
}

llvm-svn: 286748
2016-11-13 06:09:16 +00:00
Richard Smith edbc6e93e1 Reinstate r284008 reverted in r284081, with two fixes:
1) Merge and demote variable definitions when we find a redefinition in
MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach
the second case if it's the addition of the initializer itself that converts an
existing declaration into a definition). 

2) When rebuilding a redeclaration chain for a variable, if we merge two
definitions together, mark the definitions as merged so the retained definition
is made visible whenever the demoted definition would have been.

Original commit message (from r283882):

[modules] PR28752: Do not instantiate variable declarations which are not visible.

Original patch by Vassil Vassilev! Changes listed above are mine.

llvm-svn: 284284
2016-10-14 21:41:24 +00:00
Richard Smith 88d10b68e0 Revert r284008. This is us to fail to instantiate static data members in some
cases. I'm working on reducing a testcase.

llvm-svn: 284081
2016-10-12 23:29:02 +00:00
Vassil Vassilev bb8fe3175a Reinstate r283887 and r283882.
Original message:
"[modules] PR28752: Do not instantiate variable declarations which are not visible.

https://reviews.llvm.org/D24508

Patch developed in collaboration with Richard Smith!"

llvm-svn: 284008
2016-10-12 11:57:08 +00:00
Vassil Vassilev f6b491041f Revert r283887 and r283882, until the issue is understood and fixed.
llvm-svn: 283890
2016-10-11 15:51:06 +00:00
Vassil Vassilev 4b3e7388d1 [modules] PR28752: Do not instantiate variable declarations which are not visible.
https://reviews.llvm.org/D24508

Patch developed in collaboration with Richard Smith!

llvm-svn: 283882
2016-10-11 13:57:36 +00:00
Justin Lebar 28f09c50e2 [Sema] Use unique_ptr instead of raw pointers in the late-parsed templates map.
Summary:
This is possible now that MapVector supports move-only values.

Depends on D25404.

Reviewers: timshen

Subscribers: cfe-commits

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

llvm-svn: 283766
2016-10-10 16:26:08 +00:00
Vassil Vassilev e5fe5e98e5 Simplify. NFC.
llvm-svn: 281315
2016-09-13 10:36:12 +00:00
Richard Smith 54f18e8a85 PR12298 et al: don't recursively instantiate a template specialization from
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.

We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(

llvm-svn: 280190
2016-08-31 02:15:21 +00:00
Richard Smith 3f6865a8b0 Fix member call on null pointer, found by sanitizer buildbot.
llvm-svn: 279571
2016-08-23 21:12:54 +00:00
Richard Smith 6f4e2e038d Fix regression introduced by r279164: only pass definitions as the PatternDef
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.

The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.


This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.

llvm-svn: 279557
2016-08-23 19:41:39 +00:00
Chandler Carruth c6c937f2a6 Revert r279486 "Fix regression introduced by r279164"
Build bots seem unhappy and as Richard was leaving he asked me to revert
this for him. Doing so.

llvm-svn: 279500
2016-08-23 02:00:51 +00:00
Richard Smith 2fbcbb7b38 Fix regression introduced by r279164: only pass definitions as the PatternDef
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.

The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.

llvm-svn: 279486
2016-08-22 22:25:03 +00:00
Vassil Vassilev b21ee08e57 PR28794: Don't try to instantiate function templates which are not visible.
Reviewed by Richard Smith.

llvm-svn: 279164
2016-08-18 22:01:25 +00:00
Richard Smith 3997b1b427 P0217R3: template instantiation support for decomposition declarations.
llvm-svn: 278458
2016-08-12 01:55:21 +00:00
Richard Smith 32cb8c9b61 Remove unused and undesirable reference from BindingDecl to DecompositionDecl.
llvm-svn: 278448
2016-08-12 00:53:41 +00:00