TestFoundation: construct FileHandle properly on Windows
#2242
Conversation
This fixes the `FileHandle` construction on Windows so that we can continue to execute more of the tests.
|
@swift-ci please test |
| } | ||
| let fd = _open_osfhandle(intptr_t(bitPattern: hDirectory), 0) | ||
| if fd == -1 { | ||
| fatalError("unable to associate file descriptor with handle") |
There was a problem hiding this comment.
Wouldn't it be better to make this function return a FileHandle? so this can return nil and be XCTFailed by the caller, rather than stopping all of the tests?
There was a problem hiding this comment.
I followed what the old path was doing (fatal error'ing). I do like that, and since you asked, I'll go ahead and do that.
There was a problem hiding this comment.
Actually, lets do that in a follow up, I have a huge patch stack locally for the DEPLOYMENT_TARGET_* to TARGET_OS_* and that is making things more complicated.
There was a problem hiding this comment.
I took a look at this and this is really ugly without some of the internal helpers (i.e. _NSErrorWithErrno and _NSErrorWithWindowsError). Do you want to convert this to a testable import test? CC: @millenomi
There was a problem hiding this comment.
Note that expectTrue() below doesn't invoke fatalError().
There was a problem hiding this comment.
I'm not sure if we can do anything else here. Its an internal error because this implies that the handle that was provided was invalid. It would indicate an error in the test itself.
There was a problem hiding this comment.
Meaning: I'm okay error'ing out if the test is executing such that '.' is not an accessible directory for reading.
|
ping? |
This fixes the
FileHandleconstruction on Windows so that we cancontinue to execute more of the tests.