llvm-project/libcxx/test/std/thread/futures/futures.unique_future/wait_until.pass.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

127 lines
3.6 KiB
C++
Raw Normal View History

[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
//===----------------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
//
//===----------------------------------------------------------------------===//
//
// UNSUPPORTED: libcpp-has-no-threads
// UNSUPPORTED: c++03
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
// <future>
// class future<R>
// template <class Clock, class Duration>
// future_status
// wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
#include <future>
#include <atomic>
#include <cassert>
#include "make_test_thread.h"
#include "test_macros.h"
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
enum class WorkerThreadState { Uninitialized, AllowedToRun, Exiting };
typedef std::chrono::milliseconds ms;
std::atomic<WorkerThreadState> thread_state(WorkerThreadState::Uninitialized);
void set_worker_thread_state(WorkerThreadState state)
{
thread_state.store(state, std::memory_order_relaxed);
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}
void wait_for_worker_thread_state(WorkerThreadState state)
{
while (thread_state.load(std::memory_order_relaxed) != state)
std::this_thread::yield();
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}
void func1(std::promise<int> p)
{
wait_for_worker_thread_state(WorkerThreadState::AllowedToRun);
p.set_value(3);
set_worker_thread_state(WorkerThreadState::Exiting);
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}
int j = 0;
void func3(std::promise<int&> p)
{
wait_for_worker_thread_state(WorkerThreadState::AllowedToRun);
j = 5;
p.set_value(j);
set_worker_thread_state(WorkerThreadState::Exiting);
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}
void func5(std::promise<void> p)
{
wait_for_worker_thread_state(WorkerThreadState::AllowedToRun);
p.set_value();
set_worker_thread_state(WorkerThreadState::Exiting);
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}
Support tests in freestanding Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding `main` isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its `return` statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the `return` we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare `main` as `int main(int, char**` so it mangles consistently (enabling us to declare another `extern "C"` main for freestanding which calls the mangled one), and adds `return 0;` to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with `-x c`, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086
2019-02-05 04:31:13 +08:00
int main(int, char**)
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
{
typedef std::chrono::high_resolution_clock Clock;
{
typedef int T;
std::promise<T> p;
std::future<T> f = p.get_future();
support::make_test_thread(func1, std::move(p)).detach();
assert(f.valid());
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::timeout);
assert(f.valid());
// allow the worker thread to produce the result and wait until the worker is done
set_worker_thread_state(WorkerThreadState::AllowedToRun);
wait_for_worker_thread_state(WorkerThreadState::Exiting);
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::ready);
assert(f.valid());
f.wait();
assert(f.valid());
}
{
typedef int& T;
std::promise<T> p;
std::future<T> f = p.get_future();
support::make_test_thread(func3, std::move(p)).detach();
assert(f.valid());
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::timeout);
assert(f.valid());
// allow the worker thread to produce the result and wait until the worker is done
set_worker_thread_state(WorkerThreadState::AllowedToRun);
wait_for_worker_thread_state(WorkerThreadState::Exiting);
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::ready);
assert(f.valid());
f.wait();
assert(f.valid());
}
{
typedef void T;
std::promise<T> p;
std::future<T> f = p.get_future();
support::make_test_thread(func5, std::move(p)).detach();
assert(f.valid());
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::timeout);
assert(f.valid());
// allow the worker thread to produce the result and wait until the worker is done
set_worker_thread_state(WorkerThreadState::AllowedToRun);
wait_for_worker_thread_state(WorkerThreadState::Exiting);
assert(f.wait_until(Clock::now() + ms(10)) == std::future_status::ready);
assert(f.valid());
f.wait();
assert(f.valid());
}
Support tests in freestanding Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding `main` isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its `return` statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the `return` we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare `main` as `int main(int, char**` so it mangles consistently (enabling us to declare another `extern "C"` main for freestanding which calls the mangled one), and adds `return 0;` to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with `-x c`, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086
2019-02-05 04:31:13 +08:00
return 0;
[libcxx] Mark most test/std/future tests as UNSUPPORTED in C++03 Summary: This patch marks *most* tests for `std::promise`, `std::future` and `std::shared_future` as unsupported in C++03. These tests fail in C++03 mode because they attempt to copy a `std::future` even though it is a `MoveOnly` type. AFAIK the missing move-semantics in `std::future` is the only reason these tests fail but without move semantics these classes are useless. For example even though `std::promise::set_value` and `std::promise::set_exception(...)` work in C++03 `std::promise` is still useless because we cannot call `std::promise::get_future(...)`. It might be possible to hack `std::move(...)` like we do for `std::unique_ptr` to make the move semantics work but I don't think it is worth the effort. Instead I think we should leave the `<future>` header as-is and mark the failing tests as `UNSUPPORTED`. I don't believe there are any users of `std::future` or `std::promise` in C++03 because they are so unusable. Therefore I am not concerned about losing test coverage and possibly breaking users. However because there are still parts of `<future>` that work in C++03 it would be wrong to `#ifdef` out the entire header. @mclow.lists Should we take further steps to prevent the use of `std::promise`, `std::future` and `std::shared_future` in C++03? Note: This patch also cleans up the tests and converts them to use `support/test_allocator.h` instead of a duplicate class in `test/std/futures/test_allocator.h`. Reviewers: mclow.lists Subscribers: vsk, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D12135 llvm-svn: 246271
2015-08-28 13:06:04 +08:00
}