Could this get some more attention, please? This makes unusable for the clang + libstdc++ combo, requiring either Boost.Variant or libc++.

reduced test case

I'm also affected by this.

I reported this to debian BTS as well:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877838

With the help of creduce, here's a "minimal" test-case that shows the problem:

$ cat variant.cpp
namespace __detail {
namespace __variant {

template
decltype(auto) _get(const T &t) {
return t.i;
}

}
}

template class variant {
public:
variant(const T &t) : i_(t) {}
template
friend decltype(auto) __detail::__variant::_get(const Type &);
private:
T i;
};

int main() {
variant v{2};
return __detail::__variant::__get(v);
}

$ g++-7 variant.cpp -std=c++1z
$ clang++-5.0 variant.cpp -std=c++1z
variant.cpp:6:12: error: 'i_' is a private member of 'variant'
return t.i_;
^
variant.cpp:24:31: note: in instantiation of function template
specialization '__detail::__variant::__get<variant >' requested
here
return __detail::__variant::_get(v);
^
variant.cpp:18:5: note: declared private here
T i;
^
1 error generated.

I suspect this might be related to the use of decltype(auto): if I change decltype(auto) to (e.g.) int, it works.

Thanks,

Daniele

This prevents <variant> from being usable with clang++ on most modern Linux distributions (and MinGW on Windows), unless -stdlib=libc++ is used.

This is a pretty major roadblock - is this being looked into?
Should this be sent to the libstdc++ bug tracker?

Minimal example to reproduce this:

template <typename U>
auto foo(U u)
{
    u.v;
}

template <typename T>
class X
{
    T v;

public:
    template <typename U>
    friend auto foo(U);
};

int main()
{
    ::foo(X<int>{});
}

This compiles on g++, but fails to compile on clang++ trunk.

Note that calling foo(X<int>{}) (unqualified) will have the same effect (works on g++, fails on clang++), but with a different error (ambiguous foo).

This prevents <variant> from being usable with clang++ on most modern
Linux distributions (and MinGW on Windows), unless -stdlib=libc++ is used.

This is a pretty major roadblock - is this being looked into?
Should this be sent to the libstdc++ bug tracker?

I've added a workaround in https://gcc.gnu.org/r258854

Further reduced, this gives a 'conflicting types' error for 'foo':

auto foo();
template struct X {
friend auto foo();
};

Even this is rejected:

int f();
template struct X {
friend T f();
};

It looks like the function template and non-template function cases are actually two distinct bugs.

Comment#0 / comment#4 / comment#6 bugs fixed in r341778.
Comment#8 / comment #​9 bug fixed in r341775.

Comment#0 / comment#4 / comment#6 bugs fixed in r341778.
Comment#8 / comment #​9 bug fixed in r341775.

Richard are these patches OK to merge to the release_70 branch?

Richard are these patches OK to merge to the release_70 branch?

Yes.

Merged: r345409 r345412

Using gcc-9's libstdc++, which changed the check from #if defined(__clang__) to #if defined(__clang__) && __clang_major__ <= 7, we get the same issue again with clang-8. Changing it to <= 8 works as a workaround again.

So it appears to not be fixed in clang-8.

My bad, it only reports the same problem again because of the missing noexcept (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90397). Applying the patch also resolves this issue. So the bug is fixed in clang-8.

My bad, it only reports the same problem again because of the missing
noexcept (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90397). Applying
the patch also resolves this issue. So the bug is fixed in clang-8.

That was Bug 41863 which has similar symptoms.

Using libstdc++-9.1 fails for clang++-6.0 but not for clang++-7, clang++-8 and clang++-9 SVN.

mentioned in issue #38454