|
|
| Bugzilla Link |
27374 |
| Resolution |
FIXED |
| Resolved on |
Dec 08, 2016 17:58 |
| Version |
unspecified |
| OS |
All |
| Reporter |
LLVM Bugzilla Contributor |
| CC |
@mclow |
Extended Description
This bug tracks LWG issue #2419 (http://cplusplus.github.io/LWG/lwg-active.html#2419)
Calls to foo(v) can implicitly construct a n-tuple where n > 1 due to libc++'s tuple extensions. This can cause overload resolution for foo(v) to select a different overload than would otherwise be choosen for a conforming tuple implementation. For example:
#include
#include
struct base
{
void out(const std::tuple<char, char>& w) const
{
std::cerr << "Tuple: " << std::get<0>(w) << std::get<1>(w) << '\n';
}
};
struct decorator
{
base b_;
template <typename... Args>
auto
out(Args&&... args)
-> decltype(b_.out(args...))
{
return b_.out(args...);
}
void out(const char& w)
{
std::cerr << "char: " << w << '\n';
}
};
int main()
{
decorator d{base{}};
char l = 'a';
d.out(l);
}
Libc++'s tuple will cause this program to print "Tuple: a" where it should actually print "char: a".
The fix for this problem is to remove the extension on the implicit version of the UTypes... constructors.
Extended Description
This bug tracks LWG issue #2419 (http://cplusplus.github.io/LWG/lwg-active.html#2419)
Calls to foo(v) can implicitly construct a n-tuple where n > 1 due to libc++'s tuple extensions. This can cause overload resolution for foo(v) to select a different overload than would otherwise be choosen for a conforming tuple implementation. For example:
#include
#include
struct base
{
void out(const std::tuple<char, char>& w) const
{
std::cerr << "Tuple: " << std::get<0>(w) << std::get<1>(w) << '\n';
}
};
struct decorator
{
base b_;
template <typename... Args>
auto
out(Args&&... args)
-> decltype(b_.out(args...))
{
return b_.out(args...);
}
void out(const char& w)
{
std::cerr << "char: " << w << '\n';
}
};
int main()
{
decorator d{base{}};
char l = 'a';
d.out(l);
}
Libc++'s tuple will cause this program to print "Tuple: a" where it should actually print "char: a".
The fix for this problem is to remove the extension on the implicit version of the UTypes... constructors.