Commit Graph

1928 Commits

Author SHA1 Message Date
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
Saleem Abdulrasool 729379a1e1 Driver: hoist the `wchar_t` handling to the driver
Move the logic for determining the `wchar_t` type information into the
driver.  Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`.  This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.

Most of the changes to the tests are to ensure that the frontend uses
the correct type.  Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.

llvm-svn: 315126
2017-10-06 23:09:55 +00:00
Richard Smith ac63d63543 Add a "vexing parse" warning for ambiguity between a variable declaration and a
function-style cast.

This fires for cases such as

  T(x);

... where 'x' was previously declared and T is a type. This construct declares
a variable named 'x' rather than the (probably expected) interpretation of a
function-style cast of 'x' to T.

llvm-svn: 314570
2017-09-29 23:57:25 +00:00
Richard Smith 263a0a33cc Don't warn about runtime behavior problems in variable initializers that we
know are going to be constant-evaluated.

Any relevant diagnostics should be produced by constant expression evaluation.

llvm-svn: 314067
2017-09-23 18:27:11 +00:00
Richard Smith cdb06f2150 Correctly compute linkage for members of internal linkage classes.
We used to give such members no linkage instead of giving them the linkage of
the class.

llvm-svn: 314054
2017-09-23 04:02:17 +00:00
Richard Smith df963a38a9 DR1113: anonymous namespaces formally give their contents internal linkage.
This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.

We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.

We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.

llvm-svn: 314037
2017-09-22 22:21:44 +00:00
Richard Smith 7ff8304db7 Closure types have no name (and can't have a typedef name for linkage
purposes), so they never formally have linkage.

llvm-svn: 313957
2017-09-22 04:33:20 +00:00
Richard Smith aa6ce34141 Fix tracking of whether a destructor would be deleted.
I've been unable to find any cases whose behavior is actually changed by this,
but only because an implicitly deleted destructor also results in it being
impossible to have a trivial (non-deleted) copy constructor, which the place
where this really matters (choosing whether to pass a class in registers)
happens to also check.

llvm-svn: 313948
2017-09-22 01:04:22 +00:00
Richard Smith 405e2dbf37 Implement C++ [basic.link]p8.
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.

There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.

llvm-svn: 313729
2017-09-20 07:22:00 +00:00
Richard Smith f26c54f9ce Add target triple to improve the happiness of MSVC buildbots.
llvm-svn: 312749
2017-09-07 22:07:52 +00:00
Richard Smith b8c419085f Add IDNS_Tag to C++ declarations that conflict with tag declarations.
Fixes some accepts-invalids with tags and other declarations declared in the
same scope.

llvm-svn: 312743
2017-09-07 20:22:00 +00:00
Richard Smith 1363e8f6ed P0702R1: in class template argument deduction from a list of one element, if
that element's type is (or is derived from) a specialization of the deduced
template, skip the std::initializer_list special case.

llvm-svn: 312703
2017-09-07 07:22:36 +00:00
Richard Smith 80acd0fd0b [modules ts] Add test for [basic.link]p3.
llvm-svn: 312696
2017-09-07 05:29:39 +00:00
Richard Smith cd4a7a461f [modules ts] Ensure that module linkage variables are always emitted and always have their name mangled.
llvm-svn: 312684
2017-09-07 00:55:55 +00:00
Richard Smith a465362d77 [modules ts] Emit global variables in a module interface unit as part of that unit, not in importers.
llvm-svn: 312665
2017-09-06 20:01:14 +00:00
Richard Smith dd8b5337e9 Implement Itanium name mangling support for C++ Modules TS.
This follows the scheme agreed with Nathan Sidwell, which can be found here:

  https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile

This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.

llvm-svn: 312467
2017-09-04 05:37:53 +00:00
Boris Kolpackov d30446fd77 [modules] Add ability to specify module name to module file mapping (reapply)
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).

This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.

Reviewed By: rsmith

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

llvm-svn: 312220
2017-08-31 06:26:43 +00:00
Boris Kolpackov b83213e1c9 Fix path regex in test to match on Windows
llvm-svn: 312217
2017-08-31 06:18:08 +00:00
Victor Leschuk db68911b07 Revert r312105 [modules] Add ability to specify module name to module file mapping
Looks like it breaks win10 builder.

llvm-svn: 312112
2017-08-30 11:31:56 +00:00
Boris Kolpackov 7a71b4b658 [modules] Add ability to specify module name to module file mapping
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).

This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.

Reviewed By: rsmith

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

llvm-svn: 312105
2017-08-30 08:45:59 +00:00
Boris Kolpackov 734d8548ee [modules-ts] Omit submodule semantics for TS modules
If a TS module name has more than one component (e.g., foo.bar) then we
erroneously activated the submodule semantics when encountering a module
declaration in the module implementation unit (e.g., 'module foo.bar;').

Reviewed By: rsmith

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

llvm-svn: 312007
2017-08-29 15:30:18 +00:00
Faisal Vali 55bc389aeb revert changes from r311851.
The right answers here (and how clang needs to be tweaked) require further analysis (ongoing cwg thread).

sorry.

llvm-svn: 311855
2017-08-27 19:00:08 +00:00
Faisal Vali 5f5b29dd22 Don't see through 'using member-declarations' when determining the relation of any potential implicit object expression to the parent class of the member function containing the function call.
Prior to this patch clang would not error here:

  template <class T> struct B;
  
  template <class T> struct A {
    void foo();
    void foo2();
    
    void test1() {
      B<T>::foo();  // OK, foo is declared in A<int> - matches type of 'this'.
      B<T>::foo2(); // This should be an error!  
                    // foo2 is found in B<int>, 'base unrelated' to 'this'.
    }
  };

  template <class T> struct B : A<T> {
    using A<T>::foo2;
  };

llvm-svn: 311851
2017-08-27 16:49:47 +00:00
Faisal Vali 8194a3e975 [c++2a] Implement P0409R2 - Allow lambda capture [=,this] (by hamzasood)
This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency.

https://reviews.llvm.org/D36572

Thanks Hamza!

llvm-svn: 311224
2017-08-19 03:43:07 +00:00
Richard Smith f26d551387 Do not look through pack expansions when looking for unexpanded parameter packs.
Fixes a selection of rejects-valids when pack-expanding a lambda that itself
contains a pack expansion.

llvm-svn: 310972
2017-08-15 22:58:45 +00:00
Richard Smith cbaaa295f0 Replace remaining user-visible mentions of C++1z with C++17.
llvm-svn: 310804
2017-08-13 22:26:53 +00:00
Richard Smith f8c735c770 PR33850: Update cxx_dr_status for Clang 5 branch.
llvm-svn: 310692
2017-08-11 03:14:20 +00:00
Richard Smith 1283e9868d [modules ts] Basic for module linkage.
In addition to the formal linkage rules, the Modules TS includes cases where
internal-linkage symbols within a module interface unit can be referenced from
outside the module via exported inline functions / templates. We give such
declarations "module-internal linkage", which is formally internal linkage, but
results in an externally-visible symbol.

llvm-svn: 307434
2017-07-07 20:04:28 +00:00
Richard Smith b51cf1136f [modules ts] Do not emit strong function definitions from the module interface unit in every user.
llvm-svn: 307232
2017-07-06 00:30:00 +00:00
Erich Keane 7538b35cef Address comments that escaped D33333
Patch By: Jen Yu

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

llvm-svn: 307172
2017-07-05 16:43:45 +00:00
Richard Smith d19389a3c9 [modules ts] Improve merging of module-private declarations.
These cases occur frequently for declarations in the global module (above the
module-declaration) in a Modules TS module interface. When we merge a
definition from another module into such a module-private definition, ensure
that we transitively make everything lexically within that definition visible
to that translation unit.

llvm-svn: 307129
2017-07-05 07:47:11 +00:00
Richard Smith e03a654581 [modules ts] Declarations from a module interface unit are only visible outside
the module if declared in an export block. 

llvm-svn: 307115
2017-07-05 01:42:07 +00:00
Erich Keane 89fe9c269a Emit warning when throw exception in destruct or dealloc functions which has a
(possible implicit) noexcept specifier

Throwing in the destructor is not good (C++11 change try to not allow see below).
 But in reality, those codes are exist.
C++11 [class.dtor]p3:

A declaration of a destructor that does not have an exception-specification is 
implicitly considered to have the same exception specification as an implicit 
declaration.

With this change, the application worked before may now run into runtime 
termination. My goal here is to emit a warning to provide only possible info to 
where the code may need to be changed.

First there is no way, in compile time to identify the “throw” really throw out 
of the function. Things like the call which throw out… To keep this simple, 
when “throw” is seen, checking its enclosing function(only destructor and 
dealloc functions) with noexcept(true) specifier emit warning.

Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema 
in Sema.h. It is used in the call to both BuildCXXThrow and 
TransformCXXThrowExpr.

The function basic check if the enclosing function with non-throwing noexcept 
specifer, if so emit warning for it.

The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing

    noexcept specifier. Throwing exception may cause termination.
        [-Wthrow-in-dtor]
        throw 1;
        ^

        k1.cpp:43:30: note: in instantiation of member function

        'dependent_warn<noexcept_fun>::~dependent_warn' requested here

        dependent_warn<noexcept_fun> f; // cause warning

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

llvm-svn: 306149
2017-06-23 20:22:19 +00:00
Serge Pavlov 79271ab154 Do not inherit default arguments for friend function in class template.
A function declared in a friend declaration may have declarations prior
to the containing class definition. If such declaration defines default
argument, the friend function declaration inherits them. This behavior
causes problems if the class where the friend is declared is a template:
during the class instantiation the friend function looks like if it had
default arguments, so error is triggered.

With this change friend functions declared in class templates do not
inherit default arguments. Actual set of them will be defined at the
point where the containing class is instantiated.

This change fixes PR12724.

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

llvm-svn: 304965
2017-06-08 06:31:19 +00:00
Serge Pavlov 673f44c769 Improve diagnostics if friend function redefines file-level function.
Clang makes check for function redefinition after it merged the new
declaration with the existing one. As a result, it produces poor
diagnostics in the case of a friend function defined inline, as in
the code:
```
    void func() {}
    class C { friend void func() {} };
```
Error message in this case states that `inline declaration of 'func'
follows non-inline definition`, which is misleading, as `func` does
not have explicit `inline` specifier.

With this changes compiler reports function redefinition if the new
function is a friend defined inline and it does not have explicit
`inline` specifier.

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

llvm-svn: 304964
2017-06-08 06:07:07 +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
Richard Smith cd19815bc2 [c++1z] Support deducing B in noexcept(B).
This is not required by the standard (yet), but there seems to be reasonable
support for this being a defect according to CWG discussion, and libstdc++ 7.1
relies on it working.

llvm-svn: 304946
2017-06-07 21:46:22 +00:00
Richard Smith 883dbc43d9 Switch from using a DiagnosticTrap and a note for "while defining a special
member function" context notes to registering an entry on the context stack.

Also reorder the steps within defining special members to be consistent.

This has a few benefits: if multiple diagnostics are produced while checking
such a member, the note is now attached to the first such diagnostic rather
than the last, this prepares us for persisting these diagnostics between the
point at which we require the implicit instantiation of a template and the
point at which that instantiation is actually performed, and this fixes some
cases where we would fail to produce a full note stack leading back to user
code in the case of such a diagnostic.

The reordering exposed a case where we could recursively attempt to define a
defaulted destructor while we're already defining one (and other such cases
also appear to be possible, with or without this change), so this change also
reuses the "willHaveBody" flag on function declarations to track that we're in
the middle of synthesizing a body for the function and bails out if we try to
define a function that we're already defining.

llvm-svn: 303930
2017-05-25 22:47:05 +00:00
Eric Fiselier b0bac2dafb [Sema] Implement Core 2094: Trivial copy/move constructor for class with volatile member
Summary: This patch implements http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094 which reverts Core 496.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

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

llvm-svn: 302593
2017-05-09 22:21:24 +00:00
Richard Smith 145e15a37b [modules ts] Diagnose 'export' declarations outside of a module interface.
llvm-svn: 301271
2017-04-24 23:12:30 +00:00
Richard Smith 645386cf4b Rearrange some Modules TS testcases into test/CXX/modules-ts.
llvm-svn: 301066
2017-04-22 00:47:53 +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
Matthias Gehre dc01bb448f Implement DR 373 "Lookup on namespace qualified name in using-directive"
Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.

Reviewers: rsmith, aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 298126
2017-03-17 21:41:20 +00:00
Alex Lorenz 76377dcf99 Print nested name specifiers for typedefs and type aliases
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.

Patch by Michael Reiher!

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

llvm-svn: 297465
2017-03-10 15:04:58 +00:00
Richard Smith df054d3d22 C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions.
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.

This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.

We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.

llvm-svn: 296275
2017-02-25 23:53:05 +00:00
Richard Smith 1338122b25 Add context note to diagnostics that occur while declaring an implicit special member function.
llvm-svn: 296020
2017-02-23 21:43:43 +00:00
Richard Smith 73c3c21fae Fix tracking of whether the previous template instantiation stack matches the current one.
Rather than attempting to compare whether the previous and current top of
context stack are "equal" (which fails for a number of reasons, such as the
context stack entries containing pointers to objects on the stack, or reaching
the same "top of stack" entry through two different paths), track the depth of
context stack at which we last emitted a note and invalidate it when we pop the
context stack to less than that depth.

This causes us to emit some missing "in instantiation of" notes and to stop
emitting redundant "in instantiation of" stacks matching the previous stack in
rare cases.

llvm-svn: 295921
2017-02-23 02:09:03 +00:00
Richard Smith f0393bf0a5 Revert r295277 to fix buildbot.
llvm-svn: 295281
2017-02-16 04:22:56 +00:00
Richard Smith 86a1b135f0 Add missing "deduced A == A" check for function template partial ordering.
This appears to be the only template argument deduction context where we were
missing this check. Surprisingly, other implementations also appear to miss
the check in this case; it may turn out that important code is relying on
the widespread non-conformance here, in which case we'll need to reconsider.

llvm-svn: 295277
2017-02-16 03:49:44 +00:00
Vedant Kumar f4217f862a [Sema] Add lvalue-to-rvalue cast in direct-list-initialization of enum
After r264564, we allowed direct-list-initialization of an enum from an
integral value in C++1z mode, so long as that value can convert to the
enum's underlying type.

In this kind of initialization, we need a lvalue-to-rvalue conversion
for the initializer value if it is not a rvalue. This lets us accept the
following code:

  enum class A : unsigned {};
  A foo(unsigned x) { return A{x}; }

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

llvm-svn: 295266
2017-02-16 01:20:00 +00:00
Richard Smith cbe079321e [c++1z] Add some more tests for class template argument deduction, add
feature-test macro, and mark feature as done on status page.

llvm-svn: 295011
2017-02-14 00:55:25 +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 bfbff07e73 [c++1z] Diagnose attempts to use variables with deduced class template
specialization types from within their own initializers.

llvm-svn: 294796
2017-02-10 22:35:37 +00:00
Richard Smith d69f4f5b05 [c++1z] Require an initializer for deduced class template specialization types.
It's actually meaningful and useful to allow such variables to have no
initializer, but we are strictly following the standard here until the C++
committee reaches consensus on allowing this.

llvm-svn: 294785
2017-02-10 21:40:29 +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
Richard Smith 3817e4a40c [c++1z] Disallow deduction guides with deduced types that don't syntactically match the template being deduced.
llvm-svn: 294773
2017-02-10 19:49:50 +00:00
Richard Smith a2c581f42f [c++1z] In class template argument deduction, all declarators must deduce the same type (just like with auto deduction).
llvm-svn: 294700
2017-02-10 03:27:13 +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 afe4aa8b2c [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.
llvm-svn: 294693
2017-02-10 02:19:05 +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 60437620db [c++1z] P0091R3: Basic support for deducing class template arguments via deduction-guides.
llvm-svn: 294613
2017-02-09 19:17:44 +00:00
Saleem Abdulrasool a6ae060db4 Sema: add warning for c++ member variable shadowing
Add a warning for shadowed variables across records.  Referencing a
shadow'ed variable may not give the desired variable.  Add an optional
warning for the shadowing.

Patch by James Sun!

llvm-svn: 294401
2017-02-08 03:30:13 +00:00
Richard Smith c88aa3f3a6 Diagnose an attempt to give a deduction-guide a function body.
llvm-svn: 294397
2017-02-08 01:27:29 +00:00
Richard Smith 8f8697f3e1 Fix constructor declarator detection for the case when the name is followed by
an attribute-specifier-seq. (Also fixes the same problem for deduction-guides.)

llvm-svn: 294396
2017-02-08 01:16:55 +00:00
Richard Smith f283fdcd50 P0091R3: Improved syntactic checking of deduction-guides.
llvm-svn: 294395
2017-02-08 00:35:25 +00:00
Richard Smith 3584515018 P0091R3: Implement basic parsing support for C++17 deduction-guides.
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).

llvm-svn: 294266
2017-02-07 01:37:30 +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 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
Alex Lorenz 56fb6fef50 [Sema] Improve the error diagnostic for dot destructor calls on pointer objects
This commit improves the mismatched destructor type error by detecting when the
destructor call has used a '.' instead of a '->' on a pointer to the destructed
type. The diagnostic now suggests to use '->' instead of '.', and adds a fixit
where appropriate.

rdar://28766702

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

llvm-svn: 292615
2017-01-20 15:38:58 +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
Richard Smith 11255ec765 PR9551: Implement DR1004 (http://wg21.link/cwg1004).
This rule permits the injected-class-name of a class template to be used as
both a template type argument and a template template argument, with no extra
syntax required to disambiguate.

llvm-svn: 292426
2017-01-18 19:19:22 +00:00
Richard Smith 0c062b408b Give more accurate descriptions of what kind of template we found in diagnostics.
We were previouly assuming that every type template was a class template, which
is not true any more.

llvm-svn: 291988
2017-01-14 02:19:59 +00:00
Richard Smith 836a3b416d PR31606: Generalize our tentative DR resolution for inheriting copy/move
constructors to better match the pre-P0136R1 behavior.

llvm-svn: 291955
2017-01-13 20:46:54 +00:00
Malcolm Parsons 87a036259b [Sema] Add warning for unused lambda captures
Summary:
Warn when a lambda explicitly captures something that is not used in its body.

The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture.

Reviewers: rsmith, arphaman, jbcoe, aaron.ballman

Subscribers: Quuxplusone, arphaman, cfe-commits

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

llvm-svn: 291905
2017-01-13 15:01:06 +00:00
Richard Smith 8210ed5586 Implement DR1265 (wg21.link/cwg1265).
Diasllow a declaration using the 'auto' type specifier from using two different
meanings of it at once, or from declaring multiple functions with deduced
return types or introducing multiple trailing return types.

The standard does not technically disallow the multiple trailing return types
case if all the declarators declare variables (such as function pointers with
trailing return types), but we disallow that too, following the clear intent.

llvm-svn: 291880
2017-01-13 02:22:01 +00:00
Richard Smith d7279bba20 Update C++ status pages for Clang 4 branch:
* Update version number in DR tests from 4.0 to 4
 * Teach make_cxx_dr_status script about version numbers that don't contain a
   period.
 * Update cxx_status.html and cxx_dr_status.html to list Clang 4 features as
   "Clang 4" rather than "SVN"

Clang 4 features are still listed in yellow rather than green until release.

llvm-svn: 291871
2017-01-13 00:57:54 +00:00
David L. Jones f55ce36c02 Allow constexpr construction of subobjects unconditionally, not just in C++14.
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:

  struct foo_t { union { int i; volatile int j; } u; };

  __attribute__((__require_constant_initialization__))
  static const foo_t x = {{0}};

Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:

  union foo_u { int i; volatile int j; };
  __attribute__((__require_constant_initialization__))
  static const foo_u x = {0};

does have a constant initializer.

(This was triggered by musl's pthread_mutex_t type when building under C++11.)

Reviewers: rsmith

Subscribers: EricWF, cfe-commits

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

llvm-svn: 291480
2017-01-09 21:38:07 +00:00
Richard Smith 6eedfe77c1 Implement C++ DR1391 (wg21.link/cwg1391)
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.

This re-commits r290808, reverted in r290811 and r291412, with a couple of
fixes for handling of explicitly-specified non-trailing template argument
packs.

llvm-svn: 291427
2017-01-09 08:01:21 +00:00
Richard Smith de0d34a576 Implement DR1388 (wg21.link/cwg1388).
This issue clarifies how deduction proceeds past a non-trailing function
parameter pack. Essentially, the pack itself is skipped and consumes no
arguments (except for those implied by an explicitly-specified template
arguments), and nothing is deduced from it. As a small fix to the standard's
rule, we do not allow subsequent deduction to change the length of the function
parameter pack (by preventing extension of the explicitly-specified pack if
present, and otherwise deducing all contained packs to empty packs).

llvm-svn: 291425
2017-01-09 07:14:40 +00:00
Richard Smith 7950d82ab5 Revert r291410 and r291411.
The test-suite bots are still failing even after r291410's fix.

llvm-svn: 291412
2017-01-09 01:18:18 +00:00
Richard Smith d22652122d Implement C++ DR1391 (wg21.link/cwg1391)
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.

This re-commits r290808, reverted in r290811, with a fix for handling of
explicitly-specified template argument packs.

llvm-svn: 291410
2017-01-09 00:43:47 +00:00
Richard Smith f9c59b7122 PR30305: Implement proposed DR resolution to prevent slicing via inherited constructor.
The rule we use is that a construction of a class type T from an argument of
type U cannot use an inherited constructor if U is the same as T or is derived
from T (or if the initialization would first convert it to such a type). This
(approximately) matches the rule in use by GCC, and matches the current proposed
DR resolution.

llvm-svn: 291403
2017-01-08 21:45:44 +00:00
Richard Smith d6a150829b PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.

It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).

llvm-svn: 291318
2017-01-07 00:48:55 +00:00
Renato Golin dad96d6751 Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation."
This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout

Also, please, next time, try to write a commit message in according to
our guidelines:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

llvm-svn: 290811
2017-01-02 11:15:42 +00:00
Richard Smith efcfe86072 DR1391: Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside
the immediate context is much more common during substitution than during
implicit conversion sequence formation.

This does not implement the partial ordering portion of DR1391, which so
far appears to be misguided.

llvm-svn: 290808
2017-01-02 02:42:17 +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 0e617ecdd1 DR1495: A partial specialization is ill-formed if it is not (strictly) more
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)

llvm-svn: 290593
2016-12-27 07:56:27 +00:00
Richard Smith 792c22dbd4 When producing a name of a partial specialization in a diagnostic, use the
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.

llvm-svn: 290483
2016-12-24 04:09:05 +00:00
Richard Smith 593d6a168f When merging two deduced non-type template arguments for the same parameter,
fail the merge if the arguments have different types (except if one of them was
deduced from an array bound, in which case take the type from the other).

This is correct because (except in the array bound case) the type of the
template argument in each deduction must match the type of the parameter, so at
least one of the two deduced arguments must have a mismatched type.

This is necessary because we would otherwise lose the type information for the
discarded template argument in the merge, and fail to diagnose the mismatch.

In order to power this, we now properly retain the type of a deduced non-type
template argument deduced from a declaration, rather than giving it the type of
the template parameter; we'll convert it to the template parameter type when
checking the deduced arguments.

llvm-svn: 290399
2016-12-23 01:30:39 +00:00
Chandler Carruth fcd33149b4 Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
  - But not for -fno-inline-functions (breaking LTO)
  - But we did use it for -finline-hint-functions (yay, LTO is happy!)
  - But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
  enumeration and a boolean. They interacted in weird ways and
  needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
  when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
  different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
  onto many generated function definitions because they didn't show up
  as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
  inliner pass in LLVM despite it being in the O0 pipeline, which really
  doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
  pipeline which forced the pass pipeline to be much more
  parameterizable than it really needs to be. Instead we can *just* use
  the optimization level to select a pipeline and control the rest via
  attributes.

Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.

I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.

One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.

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

llvm-svn: 290398
2016-12-23 01:24:49 +00:00
Chandler Carruth 93786da2cb Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

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

llvm-svn: 290392
2016-12-23 00:23:01 +00:00
Richard Smith 16d3150852 [c++1z] When initializing a const-qualified class type, don't forget to add on
the requested cv-qualifiers after construction. This usually doesn't matter,
but it does matter within a ?: operator.

llvm-svn: 290227
2016-12-21 01:31:56 +00:00
Richard Smith 543f1acadb Add test for DR692.
llvm-svn: 290166
2016-12-20 07:24:53 +00:00
Richard Smith 4eeaec46f7 Fix name hiding and redeclaration checking for dependent local
using-declarations.

llvm-svn: 290072
2016-12-18 22:01:46 +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
Richard Smith 81f5ade227 Move checks for creation of objects of abstract class type from the various
constructs that can do so into the initialization code. This fixes a number
of different cases in which we used to fail to check for abstract types.

Thanks to Tim Shen for inspiring the weird code that uncovered this!

llvm-svn: 289753
2016-12-15 02:28:18 +00:00