Skip to content
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

Appveyor build is broken #2336

Closed
3 tasks
Rantanen opened this issue Jan 7, 2018 · 3 comments
Closed
3 tasks

Appveyor build is broken #2336

Rantanen opened this issue Jan 7, 2018 · 3 comments
Labels
C-bug Category: Clippy is not doing the correct thing

Comments

@Rantanen
Copy link
Contributor

Rantanen commented Jan 7, 2018

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#47029
    • 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.
@ghost
Copy link

ghost commented Jan 9, 2018

Regarding dogfood, why does clippy build the exe? Shouldn't the compilation stop after the lint phase?

@phansch
Copy link
Member

phansch commented Dec 2, 2018

The CRLF/LF issue should be fixed with the latest master. Newlines should now always be LF on a new clone:

[attr]rust text eol=lf whitespace=tab-in-indent,trailing-space,tabwidth=4
* text=auto eol=lf
*.rs rust

@phansch
Copy link
Member

phansch commented Dec 18, 2020

We're not using Appveyor anymore, so closing this.

@phansch phansch closed this as completed Dec 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing
Projects
None yet
Development

No branches or pull requests

2 participants