-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify that 8-bit exit codes aren't a problem on macOS and Windows. #603
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@swift-ci please test |
Looks like Linux, or at least our CI's version, does not correctly implement |
@swift-ci please test |
The documentation for the experimental exit tests feature currently says that on POSIX-like systems, only the low 8 bits of a process' exit code are preserved. This would be true if we used `wait()`, `wait4()`, etc. and `WEXITSTATUS()`, but we use `waitid()` instead which is [supposed to](https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html) preserve the full exit code. Now, we're not currently building for any other POSIX-like systems that support processes (WASI/Wasm doesn't count here), so I've left in some weasel words and added a canary unit test. It will let us know if/when we add a platform that where `waitid()` doesn't preserve all the bits of the exit code, and we can amend the documentation in that case. Exit tests remain an experimental feature only.
6ff8bef
to
761c98b
Compare
@swift-ci please test |
grynspan
added a commit
that referenced
this pull request
Aug 15, 2024
grynspan
added a commit
that referenced
this pull request
Aug 15, 2024
This PR supersedes #603, #613, and #614. Exit tests remain an experimental feature. ## Clarify that 8-bit exit codes aren't a problem on macOS and Windows. (#603) The documentation for the experimental exit tests feature currently says that on POSIX-like systems, only the low 8 bits of a process' exit code are preserved. This would be true if we used `wait()`, `wait4()`, etc. and `WEXITSTATUS()`, but we use `waitid()` instead which is [supposed to](https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html) preserve the full exit code. It does so on Darwin, but not on Linux; Windows doesn't use `waitid()` but does report the full exit code. Now, we're not currently building for any other POSIX-like systems that support processes (WASI/Wasm doesn't count here), so I've left in some weasel words and added a canary unit test. It will let us know if/when we add a platform that where `waitid()` doesn't preserve all the bits of the exit code, and we can amend the documentation in that case. ## Implement an equality operator for ExitCondition. (#613) This PR implements `==` and `===` for `ExitCondition`, part of the experimental exit tests feature. These operators are necessary in order to allow for exit tests to support more complex matching by trailing closure (e.g. to support inspecting `stdout`.) Because `.failure` is a fuzzy case, `==` fuzzy-matches while `===` exactly matches. `Hashable` conformance is unavailable. Example usage: ```swift let lhs: ExitCondition = .failure let rhs: ExitCondition = .signal(SIGTERM) print(lhs == rhs) // prints "true" print(lhs === rhs) // prints "false" ``` ## Allow throwing an error from an exit test's body. (#614) This PR amends the signatures of the exit test macros (`#expect(exitsWith:) {}` and `try #require(exitsWith:) {}`) to allow bodies to throw errors. If they do, they are treated as uncaught errors and the child process terminates abnormally (in the same way it does if an error is thrown from the main function of a Swift program.)
Superseded by #615. |
grynspan
added a commit
that referenced
this pull request
Aug 15, 2024
This PR supersedes #603, #613, and #614. Exit tests remain an experimental feature. ## Clarify that 8-bit exit codes aren't a problem on macOS and Windows. (#603) The documentation for the experimental exit tests feature currently says that on POSIX-like systems, only the low 8 bits of a process' exit code are preserved. This would be true if we used `wait()`, `wait4()`, etc. and `WEXITSTATUS()`, but we use `waitid()` instead which is [supposed to](https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html) preserve the full exit code. It does so on Darwin, but not on Linux; Windows doesn't use `waitid()` but does report the full exit code. Now, we're not currently building for any other POSIX-like systems that support processes (WASI/Wasm doesn't count here), so I've left in some weasel words and added a canary unit test. It will let us know if/when we add a platform that where `waitid()` doesn't preserve all the bits of the exit code, and we can amend the documentation in that case. ## Implement an equality operator for ExitCondition. (#613) This PR implements `==` and `===` for `ExitCondition`, part of the experimental exit tests feature. These operators are necessary in order to allow for exit tests to support more complex matching by trailing closure (e.g. to support inspecting `stdout`.) Because `.failure` is a fuzzy case, `==` fuzzy-matches while `===` exactly matches. `Hashable` conformance is unavailable. Example usage: ```swift let lhs: ExitCondition = .failure let rhs: ExitCondition = .signal(SIGTERM) print(lhs == rhs) // prints "true" print(lhs === rhs) // prints "false" ``` ## Allow throwing an error from an exit test's body. (#614) This PR amends the signatures of the exit test macros (`#expect(exitsWith:) {}` and `try #require(exitsWith:) {}`) to allow bodies to throw errors. If they do, they are treated as uncaught errors and the child process terminates abnormally (in the same way it does if an error is thrown from the main function of a Swift program.)
grynspan
added a commit
that referenced
this pull request
Aug 21, 2024
This PR supersedes #603, #613, and #614. Exit tests remain an experimental feature. ## Clarify that 8-bit exit codes aren't a problem on macOS and Windows. (#603) The documentation for the experimental exit tests feature currently says that on POSIX-like systems, only the low 8 bits of a process' exit code are preserved. This would be true if we used `wait()`, `wait4()`, etc. and `WEXITSTATUS()`, but we use `waitid()` instead which is [supposed to](https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html) preserve the full exit code. It does so on Darwin, but not on Linux; Windows doesn't use `waitid()` but does report the full exit code. Now, we're not currently building for any other POSIX-like systems that support processes (WASI/Wasm doesn't count here), so I've left in some weasel words and added a canary unit test. It will let us know if/when we add a platform that where `waitid()` doesn't preserve all the bits of the exit code, and we can amend the documentation in that case. ## Implement an equality operator for ExitCondition. (#613) This PR implements `==` and `===` for `ExitCondition`, part of the experimental exit tests feature. These operators are necessary in order to allow for exit tests to support more complex matching by trailing closure (e.g. to support inspecting `stdout`.) Because `.failure` is a fuzzy case, `==` fuzzy-matches while `===` exactly matches. `Hashable` conformance is unavailable. Example usage: ```swift let lhs: ExitCondition = .failure let rhs: ExitCondition = .signal(SIGTERM) print(lhs == rhs) // prints "true" print(lhs === rhs) // prints "false" ``` ## Allow throwing an error from an exit test's body. (#614) This PR amends the signatures of the exit test macros (`#expect(exitsWith:) {}` and `try #require(exitsWith:) {}`) to allow bodies to throw errors. If they do, they are treated as uncaught errors and the child process terminates abnormally (in the same way it does if an error is thrown from the main function of a Swift program.) ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
darwin
🍎 macOS, iOS, watchOS, tvOS, and visionOS support
documentation
Improvements or additions to documentation
exit-tests
☠️ Work related to exit tests
linux
🐧 Linux support (all distros)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The documentation for the experimental exit tests feature currently says that on POSIX-like systems, only the low 8 bits of a process' exit code are preserved. This would be true if we used
wait()
,wait4()
, etc. andWEXITSTATUS()
, but we usewaitid()
instead which is supposed to preserve the full exit code. It does so on Darwin, but not on Linux; Windows doesn't usewaitid()
but does report the full exit code.Now, we're not currently building for any other POSIX-like systems that support processes (WASI/Wasm doesn't count here), so I've left in some weasel words and added a canary unit test. It will let us know if/when we add a platform that where
waitid()
doesn't preserve all the bits of the exit code, and we can amend the documentation in that case.Exit tests remain an experimental feature only.
Checklist: