Commit Graph

3 Commits

Author SHA1 Message Date
Eric Fiselier
e428b57e79 Fix diagnostic test to tolerate Clang diagnosing it as well.
Tuple has tests that ensure we diagnose non-lifetime extended
reference bindings inside tuples constructors. As of yesterday,
Clang now does this for us.

Adjust the test to tolerate the new diagnostics, while still
testing that we emit diagnostics of our own. Maybe after this
version of Clang has been adopted by most users we should
remove our diagnostics; but for now more error detection is
better!

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337905 91177308-0d34-0410-b5e6-96231b3b80d8
2018-07-25 11:16:39 +00:00
Eric Fiselier
8286acce44 [libc++] Fix PR20855 -- libc++ incorrectly diagnoses illegal reference binding in std::tuple.
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855

Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:

```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```

However, we are over-aggressive and we incorrectly diagnose cases such as:

```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```

This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:

```
std::tuple<int, const std::string&> t(42, "abc");
```

Reviewers: rsmith, mclow.lists

Reviewed By: rsmith

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@323380 91177308-0d34-0410-b5e6-96231b3b80d8
2018-01-24 22:14:01 +00:00
Eric Fiselier
f2f3637d40 Fix PR27374 - Remove the implicit reduced-arity-extension in tuple.
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:

    int fun(std::string);
    int fun(std::tuple<std::string, int>);
    int x = fun("hello"); // ambigious

Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.

Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.

git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289158 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-08 23:57:08 +00:00