metabug: problems from check-fast being sole test driver #8844
Labels
metabug
Issues about issues themselves ("bugs about bugs")
Comments
|
See also #4193 |
This was referenced Aug 29, 2013
|
Note also that Sully's suggestion from #8456 makes an interesting suggestion of running |
|
check-fast may also be useful for Android, since running a test involves spawning adb, adb copying the test binary to the remote device, spawning adb again, and adb talking to the remote device to spawn the copied test binary, or something like that. |
|
Windows may be not entirely at fault for slow process spawning: #8859 |
brson
added a commit
to brson/rust
that referenced
this issue
Feb 25, 2014
brson
added a commit
to brson/rust
that referenced
this issue
Mar 22, 2014
alexcrichton
pushed a commit
to alexcrichton/rust
that referenced
this issue
Apr 5, 2014
alexcrichton
pushed a commit
to alexcrichton/rust
that referenced
this issue
Apr 6, 2014
|
Closing, #13288 removed check-fast |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jun 4, 2022
Check `.fixed` paths' existence in `run_ui` This PR adds a test to check that there exists a `.fixed` file for every `.stderr` file in `tests/ui` that mentions a `MachineApplicable` lint. The test leverages `compiletest-rs`'s `rustfix_coverage` option. I tried to add `.fixed` files where they appeared to be missing. However, 38 exceptional `.rs` files remain. Several of those include comments indicating that they are exceptions, though not all do. Apologies, as I have not tried to associate the 38 files with GH issues. (I think that would be a lot of work, and I worry about linking the wrong issue.) changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Windows, since process spawning is very slow, we use the strategy of combining a (large) subset of the tests into one program, and then compiling that once and running it.
This strategy has some drawbacks/weaknesses, and has introduced some problems.
This metabug is a place to relate those issues. The intention is to collect problems that arise from the check-fast target itself; that is, problems that would affect any use of check-fast as a sole test driver for a target (as opposed to problems that would affect Windows alone; i.e. if we were to port to some a new target platform that also only used check-fast as its test target).
The text was updated successfully, but these errors were encountered: