xd009642 / tarpaulin

A code coverage tool for Rust projects
https://crates.io/crates/cargo-tarpaulin
Apache License 2.0
2.54k stars 179 forks source link

Tarpaulin forces other commands to recompile everything #1076

Closed codybloemhard closed 2 years ago

codybloemhard commented 2 years ago

Describe the bug Tarpaulin (lately) forces other commands to recompile everything. So when I change nothing in the project (code, Cargo.toml, anything) and cargo tarpaulin all other commands such as cargo run, cargo check, cargo clippy etc will recompile everything.

rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.63.0 (4b91a6ea7 2022-08-08)`

target is stable-x86_64-unknown-linux-gnu uname -a: Linux mememman 5.18.16-artix1-1 #1 SMP PREEMPT_DYNAMIC Wed, 03 Aug 2022 13:26:46 +0000 x86_64 GNU/Linux

It used to work correctly and now it has this bug on all my projects to I don't think the code matters.

some verbose output:

verbose output Aug 18 12:51:32.064 DEBUG cargo_tarpaulin: set up logging Aug 18 12:51:32.065  INFO cargo_tarpaulin::config: Creating config Aug 18 12:51:32.241  INFO cargo_tarpaulin: Running Tarpaulin Aug 18 12:51:32.241  INFO cargo_tarpaulin: Building project Aug 18 12:51:32.241  INFO cargo_tarpaulin::cargo: Cleaning project Aug 18 12:51:44.163 DEBUG cargo_tarpaulin::cargo: Linker paths: [] Aug 18 12:51:44.206  INFO cargo_tarpaulin::process_handling::linux: Launching test Aug 18 12:51:44.206  INFO cargo_tarpaulin::process_handling: running /home/cody/git/mangatrans/target/debug/deps/mangatrans-078e0c12e93409d8 Aug 18 12:51:44.206 DEBUG cargo_tarpaulin::process_handling: Current working dir: Ok("/home/cody/git/mangatrans") Aug 18 12:51:44.207 DEBUG cargo_tarpaulin::process_handling: Env vars: [("CARGO", "/home/cody/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo"), ("CARGO_HOME", "/home/cody/.cargo"), ("DISPLAY", ":0"), ("GTK_IM_MODULE", "fcitx"), ("HOME", "/home/cody"), ("I3SOCK", "/run/user/1001/i3/ipc-socket.2472"), ("LANG", "en_US.UTF-8"), ("LD_LIBRARY_PATH", "/home/cody/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib"), ("LOGNAME", "cody"), ("LS_COLORS", "rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:"), ("MAIL", "/var/spool/mail/cody"), ("MOTD_SHOWN", "pam"), ("PATH", "/home/cody/.cargo/bin:/home/cody/scripts:/home/cody/.fzf/bin:/home/cody/.cargo/bin:/home/cody/scripts:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/cody/.local/bin:/home/cody/.local/bin"), ("PWD", "/home/cody/git/mangatrans"), ("QT_IM_MODULE", "fcitx"), ("RUSTUP_HOME", "/home/cody/.rustup"), ("RUSTUP_TOOLCHAIN", "stable-x86_64-unknown-linux-gnu"), ("RUST_BACKTRACE", "1"), ("RUST_RECURSION_COUNT", "1"), ("SDL_IM_MODULE", "fcitx"), ("SHELL", "/usr/bin/fish"), ("SHLVL", "1"), ("SSL_CERT_DIR", "/etc/ssl/certs"), ("SSL_CERT_FILE", "/etc/ssl/cert.pem"), ("STARSHIP_SESSION_KEY", "2402312106249819"), ("STARSHIP_SHELL", "fish"), ("TERM", "st-256color"), ("USER", "cody"), ("WINDOWID", "33554438"), ("WINDOWPATH", "1"), ("XAUTHORITY", "/home/cody/.Xauthority"), ("XDG_RUNTIME_DIR", "/run/user/1001"), ("XDG_SEAT", "seat0"), ("XDG_SESSION_CLASS", "user"), ("XDG_SESSION_ID", "1"), ("XDG_SESSION_TYPE", "tty"), ("XDG_VTNR", "1"), ("XMODIFIERS", "@im=fcitx"), ("RUST_BACKTRACE", "1"), ("CARGO_PKG_NAME", "mangatrans"), ("CARGO_PKG_VERSION", "0.1.0"), ("CARGO_PKG_AUTHORS", ""), ("CARGO_MANIFEST_DIR", "/home/cody/git/mangatrans")] Aug 18 12:51:44.207 DEBUG cargo_tarpaulin::process_handling: Args: ["/home/cody/git/mangatrans/target/debug/deps/mangatrans-078e0c12e93409d8", "--test-threads", "16"] running 5 tests (normal test output follows)

To Reproduce cargo check recompiles cargo run cargo test cargo clippy cargo check cargo tarpaulin recompiles cargo check recompiles cargo build cargo check cargo check cargo tarpaulin recompiles cargo check recompiles cargo check cargo check etc.

Expected behavior I expect other commands not to recompile after tarpaulin runs. It seems tarpaulin removes build files or something, something the others rely on. In the past the behaviour was as expected. The expected version of the above example is: cargo check recompiles cargo run cargo test cargo clippy cargo check might recompile cargo tarpaulin cargo check cargo build cargo check cargo check cargo tarpaulin cargo check cargo check cargo check etc.

xd009642 commented 2 years ago

You can do --skip-clean but tarpaulin does change the RUSTFLAGs so often things just have to be recompiled. I think --force-clean is probably the default now just because whenever I switch the default behaviour a few weeks later some people pop up with bugs caused by incremental compilation :man_shrugging:

codybloemhard commented 2 years ago

Hi, I just tried cargo tarpaulin --skip-clean but I does not prevent cargo check from recompiling the whole project.

xd009642 commented 2 years ago

Probably down to the rustflags change. You can use cargo tarpaulin --print-rust-flags to print what they are and do a cargo check with those flags and in theory it should not clean.

Ultimately, if check erroneously recompiles after tarpaulin is ran that's not a tarpaulin issue (but I think check is right to recompile here given a rustflag change). One solution some people use is they use the --target-dir folder to move tarpaulin builds into a different place that check/build/test builds to cut down on recompiles

codybloemhard commented 2 years ago

If it's not a bug but expected behaviour I don't quite understand what is going on. If it's because tarpaulin uses different flags, did that mean that very recently the flags of the standard cargo commands were the same as the tarpaulin flags since i did not have to recompile? If i use --target-dir as you suggest, it indeed fixes the issue of all other commands having to recompile. However, even with the use of --target-dir back to back uses of tarpaulin without any change to the code and without any other commands run in between will still recompile everything (every dependency too). This also was not the case before the tarpaulin behaviour changed on my part, I could run it back to back and it definitely didn't recompile dependencies.

xd009642 commented 2 years ago

Well which tarpaulin version did you notice behaviour change? And no tarpaulin's always used different rustflags, but there were some rustc bugs last year (or maybe 2020) where incremental compilation didn't cause things to rebuild if certain compiler flags changed causing miscompilations. So tbh things could have been changed in compiler that impact it.

And are you doing cargo tarpaulin --target-dir $NEW_DIR --skip-clean ? Remember cleaning is forced unless you use --skip-clean

codybloemhard commented 2 years ago

My mistake, I didn't include the skip clean on top of the target dir indeed. cargo tarpaulin --target-dir $NEW_DIR --skip-clean gives me the same behaviour as I used to have with plain cargo tarpaulin. I updated recently to rust stable 1.63.0, maybe indeed something changed and the interaction with tarpaulin changed. The very sudden change made me think there might be a bug, sorry about that.