Created attachment 17037 [details] compilation error message I encountered this error when trying to use libcxx from 3.9 release and trunk from around August 1st. The same code works with 3.8 release Repro: compile following example with libc++: clang -c -std=c++14 repro.cpp -stdlib=libc++ // repro.cpp // this is minimized code from folly library #include<tuple> template<class Value> struct Optional { // implicit Optional(const Value& newValue) {} }; struct dynamic { // implicit template<class T> dynamic(T t); }; Optional<std::tuple<dynamic>> get(); void test() { auto x = get(); }
Darn it.
Eric, can you give an assessment of the severity of this bug and how intrusive a fix might be? At this stage in the 3.9 process (rc3 was just tagged), I'm reluctant to take patches for anything but regressions from earlier release candidates.
> Eric, can you give an assessment of the severity of this bug and how intrusive a fix might be? It's a regression from 3.8 and tuple tends to get a lot of usage, and breakage is often noticed by many users. That's why I would like to fix this before 3.9. The fix should hopefully be small. I'll give a more complete analysis tomorrow.
So this may be a Clang bug. It seems that GCC accepts the reproducer just fine. I still would like to see this fixed in Clang before 3.9 but that might be a harder change to make.
Attempted fix: https://reviews.llvm.org/D23978 The bug seems to be caused only when `__enable_implicit()` is defined as a constexpr function. Defining it as a alias template fixes the bug. I have no idea why this changes anything or why the original error is generated at all.
(In reply to comment #5) > Attempted fix: https://reviews.llvm.org/D23978 > > The bug seems to be caused only when `__enable_implicit()` is defined as a > constexpr function. Defining it as a alias template fixes the bug. I have no > idea why this changes anything or why the original error is generated at all. Richard, can you shed some light on why the proposed patch makes a difference here?
After speaking with Richard about this, it sounds like we don't have a lot of good options to choose from here (there seems to be both issues with Clang and the C++ standard library). Taking Eric's D23978 is probably the least bad thing, doesn't make anything worse, and will fix this PR. So can we go ahead and land it?
I have no reservations, and Richard's word is good enough for me in this case. :) We can change that on trunk later, if necessary.
Update: I choose not to fix this bug in libc++ for 3.9.0 for two reasons: 1. This was also caused by a Clang bug, which was fixed shortly after the 3.9.0 release and it has been applied to the upcoming 3.9.1 release. I didn't want to re-write large portions of std::tuple right before a release in order to avoid a Clang bug. 2. The reproducer has a cyclic SFINAE condition, and I would consider that UB. Closing this bug as resolved fixed since it compiles with ToT clang.
*** Bug 34895 has been marked as a duplicate of this bug. ***
See https://reviews.llvm.org/D23999 for more information.