You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suggest disabling windows-gnu while the above issue is open.
32-bit tests are broken in general. Travis never runs these so the failures don't matter there.
I believe the underlying cause is missing the expected .stderr output for the transmute_32bit tests. Unfortunately the script for generating these is a shell-script for unix systems. Anyone have a working 32-bit cross compilation env that can run shell scripts?
dogfood test fails on permissions. Can't build cargo-clippy while cargo-clippy is running. Windows locks the executable and prevents modifying it while it's being executed.
One option would be to copy the cargo-clippy.exe under a different name before running the test itself.
Another option would be to use cargo run --release to build a release version while clippy itself would attempt to build a debug version. However this would also require building release version of clippy-driver which isn't a direct dependency of cargo-clippy.
Other failures
Plus a pile of random test failures tied to CRLF/LF differences. These don't seem to matter for Appveyor, but do fail on my local Windows machine. Ensuring the stderr/stdout reference files use LF line endings is a start. There's also a couple of places in the lints where this difference affects the output.
needless_continue.rs skips whitespace using only \n as match. On Windows \r might exist in the file as well.
doc.rs fails in calculating the word positions within /*...*/ comment blocks. I believe this is caused by Rust stripping \rs from the #[doc(..) attributes so they aren't included in the line lengths, but they are still part of the span information maybe. Tried having a look at this, but never found the root cause. Adding a random -1 length/offset per line somewhere there "fixed" the issue on Windows so it seems to be off-by-one error per line.
method.rs I believe had a failure as well, but didn't dig into it when I realized these weren't Appveyor failures.
The text was updated successfully, but these errors were encountered:
Appveyor failures:
windows-gnu
target doesn't support compiler plugins currently: GNU toolchain on Windows can't build compiler plugins since nightly 2017-12-15. rust#47029windows-gnu
while the above issue is open..stderr
output for thetransmute_32bit
tests. Unfortunately the script for generating these is a shell-script for unix systems. Anyone have a working 32-bit cross compilation env that can run shell scripts?cargo-clippy
whilecargo-clippy
is running. Windows locks the executable and prevents modifying it while it's being executed.cargo-clippy.exe
under a different name before running the test itself.cargo run --release
to build a release version while clippy itself would attempt to build a debug version. However this would also require building release version ofclippy-driver
which isn't a direct dependency ofcargo-clippy
.Other failures
Plus a pile of random test failures tied to CRLF/LF differences. These don't seem to matter for Appveyor, but do fail on my local Windows machine. Ensuring the
stderr
/stdout
reference files use LF line endings is a start. There's also a couple of places in the lints where this difference affects the output.needless_continue.rs
skips whitespace using only\n
as match. On Windows\r
might exist in the file as well.doc.rs
fails in calculating the word positions within/*...*/
comment blocks. I believe this is caused by Rust stripping\r
s from the#[doc(..)
attributes so they aren't included in the line lengths, but they are still part of the span information maybe. Tried having a look at this, but never found the root cause. Adding a random -1 length/offset per line somewhere there "fixed" the issue on Windows so it seems to be off-by-one error per line.method.rs
I believe had a failure as well, but didn't dig into it when I realized these weren't Appveyor failures.The text was updated successfully, but these errors were encountered: