test tests/ui/entry.rs failing on nightly-2021-10-10
#299
Comments
timrobertsdev
changed the title
test tests/ui/entry.rs failingtest tests/ui/entry.rs failing on nightly-2021-10-10
|
Looks like rust-lang/rust#89795 |
nicholasbishop
added a commit
to nicholasbishop/uefi-rs
that referenced
this issue
Oct 15, 2021
This test is failing in nightly due to: rust-lang/rust#89795 Disabling the test for now to get the CI happy again. Will keep rust-osdev#299 open as a reminder to re-enable the test once the underlying issue has been fixed.
nicholasbishop
added a commit
that referenced
this issue
Oct 15, 2021
This test is failing in nightly due to: rust-lang/rust#89795 Disabling the test for now to get the CI happy again. Will keep #299 open as a reminder to re-enable the test once the underlying issue has been fixed.
|
I've temporarily disabled the test with #300. Will keep this bug open as a reminder to re-enable the test once the underlying issue is fixed. |
nicholasbishop
added a commit
to nicholasbishop/uefi-rs
that referenced
this issue
Oct 27, 2021
This reverts commit a4f4fd2. The upstream issue that was causing these tests to fail has been fixed: rust-lang/rust#89795 Fixes rust-osdev#299
nicholasbishop
added a commit
that referenced
this issue
Oct 27, 2021
This reverts commit a4f4fd2. The upstream issue that was causing these tests to fail has been fixed: rust-lang/rust#89795 Fixes #299
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Linux, the
uitest for theentryattribute are failing due to a warning being emitted before the expected output.Output:
WARN rustc_metadata::locator no metadata found: failed to mmap rmeta metadata: '$WORKSPACE/target/tests/target/x86_64-unknown-linux-gnu/debug/deps/libuefi_macros_tests-ec1cf1694a730703.rmeta'I have confirmed that
$WORKSPACE/target/tests/target/x86_64-unknown-linux-gnu/debug/deps/libuefi_macros_tests-ec1cf1694a730703.rmetaexists, but it is an empty file. Not quite sure what's going on yet, as I'm not too familiar with the inner workings ofcargoandrustc.This is also failing on Windows using the MSVC toolchain, but with a different error.
Output:
ERROR: failed to execute cargo: %1 is not a valid Win32 application. (os error 193)There doesn't appear to be anything in the last few commits that would cause this; I'm leaning towards it being a bug in
rustc/cargo. It's getting late here now, I'll try some differentnightlyversions tomorrow to figure out what's going on.Steps to reproduce:
mastercd uefi-rs/uefi-test-runner./build.py testEnvironment (Linux):
rustc --version:rustc 1.57.0-nightly (41dfaaa3c 2021-10-10)Environment (Windows):
rustc --version:rustc 1.57.0-nightly (41dfaaa3c 2021-10-10)The text was updated successfully, but these errors were encountered: