Tests: add a workaround for Windows #334
Conversation
|
@swift-ci please test |
| @@ -56,7 +60,11 @@ class AsyncAwaitTests: XCTestCase { | |||
|
|
|||
| override func setUp() async throws {} | |||
|
|
|||
| override func tearDown() async throws {} | |||
| override func tearDown() async throws { | |||
There was a problem hiding this comment.
Makes sense, although I wonder if it would be ever-so-slightly more robust to place this flush in an override of the class-level tearDown method rather than this instance one? The class one isn't async but it runs later, after all tests and their tearDown methods complete, so it would theoretically be more inclusive in case there were stdout generated after an instance tearDown. I.e.
| override func tearDown() async throws { | |
| override class func tearDown() { |
There was a problem hiding this comment.
I think that I am going to disable the test on Windows instead. I noticed that the runtime was triggering asserts, and I think that is the core issue and that the flush might be a red herring. Sorry about the change of approach.
|
Hmm, when I went to test this, I happened to notice an assertion in the runtime. I think that it might be that we should just temporarily disable this one test on Windows. I can try to look into the runtime assertion subsequently. |
Disable this test on Windows as this is exposing a latent UB in the Concurrency runtime. It seems better to safely disable this test on Windows for the time being until the runtime is fixed.
|
@swift-ci please test |
The Windows test regularly fails if the stdout is not flushed on
completion. This increases the stability of the tests on Windows
(though there is another async related issue lurking that causes a
sporadic failure).