[llvm-bugs] [Bug 33236] New: clang-cl emits bogus error: cannot decompose this type; 'std::tuple_size<const S>::value' is not a valid integral constant expression

via llvm-bugs llvm-bugs at lists.llvm.org
Tue May 30 15:47:27 PDT 2017


            Bug ID: 33236
           Summary: clang-cl emits bogus error: cannot decompose this
                    type; 'std::tuple_size<const S>::value' is not a valid
                    integral constant expression
           Product: clang
           Version: 4.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sfinae at hotmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18545
  --> https://bugs.llvm.org/attachment.cgi?id=18545&action=edit
Self-contained test case

Note: This is using my implementation of LWG 2770 tuple_size SFINAE, which will
ship in VS 2017's first toolset update (aka "15.3").

C:\Temp>type meow.cpp
#include <assert.h>
#include <tuple>

struct S {
    int x;

int main() {
    S s{99};
    auto [m1] = s;
    auto& [r1] = s;
    assert(m1 == 99);
    assert(&r1 == &s.x);

    const S cs{1729};
    auto [m2] = cs;
    auto& [r2] = cs;
    assert(m2 == 1729);
    assert(&r2 == &cs.x);

Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25326 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow

C:\Temp>clang-cl -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: S:\WCFB01\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest meow.cpp && meow
meow.cpp(17,11):  error: cannot decompose this type; 'std::tuple_size<const
S>::value' is not a valid integral constant expression
    auto& [r2] = cs;
1 error generated.

I believe that this is the same issue as what I reported to the reflectors on
April 3, 2017. C1XX has implemented my preferred resolution.

Subject: [isocpp-lib] New issue - Core and Library disagree on tuple_size

LWG 2770's resolution taught tuple_size to SFINAE. However, Core's wording for
structured bindings disagrees with what the Library provides.

N4659 [tuple.helper]/4: "template <class T> class tuple_size<const T>;
template <class T> class tuple_size<volatile T>; template <class T> class
tuple_size<const volatile T>; Let TS denote tuple_size<T> of the cv-unqualified
type T. If the expression TS::value is well-formed when treated as an
unevaluated operand, then each of the three templates shall meet the
UnaryTypeTrait requirements (23.15.1) with a base characteristic of
integral_constant<size_t, TS::value> Otherwise, they shall have no member

When the Library provides SFINAE, Meow<Types> is complete, it's just that
Meow<Types>::value or Meow<Types>::type is non-existent. This is the
long-standing practice followed by invoke_result, etc.

However, Core expects different behavior:

11.5 [dcl.struct.bind]/3: "Otherwise, if the qualified-id std::tuple_size<E>
names a complete type, the expression std::tuple_size<E>::value shall be a
well-formed integral constant expression and"

This wording was introduced in Issaquah as the resolution of GB 20 (thanks to
Casey for the programmer-archaeology). He found no discussion, just "ready for
vote on Friday".

I encountered this because I implemented tuple_size SFINAE with the traditional
approach (it is a complete class with no members), yet libc++ had a test
expecting tuple_size<const void> to be an incomplete class. I argue that the
Core wording should change - it should not inspect the completeness of
tuple_size<E>, but should instead inspect the well-formedness of
tuple_size<E>::value, which is what the Library is already doing when
implementing tuple_size<cv T>.


You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170530/ce65fb59/attachment.html>

More information about the llvm-bugs mailing list