e1d4f2a0c2
And introduce two new directives for ui tests: * `run-crash` * `run-fail-or-crash` Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement. Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d`. Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127". Some tests behave differently on different targets: * Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets. * Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests. |
||
|---|---|---|
| .. | ||
| channel-stack-overflow-issue-102246.rs | ||
| fs-nul-byte-paths.rs | ||
| issue-3563-3.rs | ||
| issue-3563-3.stderr | ||
| issue-81357-unsound-file-methods.rs | ||
| stdio-from.rs | ||
| thread-sleep-ms.rs | ||
| windows-bat-args.rs | ||
| windows-bat-args1.bat | ||
| windows-bat-args2.bat | ||
| windows-bat-args3.bat | ||