rustc 1.46 takes 30+ minutes to recompile repo which used to recompile in 15 seconds under 1.45 (regression)

[fschutt]

I have a repository (a simple actix-web server) that isn't compiling anymore, because the compiler takes way too long (about 30 minutes) to recompile the crate. The repo re-compiles fine in about 30 seconds on 1.45-stable, but on 1.46-stable and nightly it takes 30+ minutes. I've cloned my repository as it is now: https://github.com/fschutt/example-actix-site

To compile it, just do cargo build (the server won't run, but it should build). A few days ago, this exact repo compiled in about about 3 - 5 minutes from scratch and it took about 15 - 30 seconds to rebuild. After upgrading the compiler to 1.46 or nightly, it builds very very slowly and when I run it with -Ztimings cargo simply sigkills rustc because it's taking too long. When running without -Ztimings, it does build, but it takes 30+ minutes to do so.

Today, I tested that the bug happens both on the latest stable version and the latest nightly version (2020-10-03), and verified that the bug happens on both Windows and Linux. I also verified that it doesn't happen on 1.45.0-stable.

Meta

Succeeded on 1.45.0-stable:

rustc 1.45.0 (5c1f21c3b 2020-07-13)
binary: rustc
commit-hash: 5c1f21c3b82297671ad3ae1e8c942d2ca92e84f2
commit-date: 2020-07-13
host: x86_64-unknown-linux-gnu
release: 1.45.0
LLVM version: 10.0

Failed on Windows (nightly 1.48 + 1.46), Linux (nightly 1.48 + 1.46)

rustc 1.48.0-nightly (8876ffc92 2020-10-02)
binary: rustc
commit-hash: 8876ffc9235dade728e1fbc4be4c85415fdd0bcd
commit-date: 2020-10-02
host: x86_64-unknown-linux-gnu
release: 1.48.0-nightly
LLVM version: 11.0

Notice the difference in the LLVM version, possibly related to #66617?

"Include a backtrace" - yeah that's the funny part, there is no backtrace because rustc gets a 9 SIGKILL because of a timeout. Sadly I don't have a backtrace.

The log I can perceive is this:

$ rustup update nightly && rustup default nightly && cargo clean && RUST_BACKTRACE=full RUSTFLAGS="-Ztime-passes" cargo build > out.txt

info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.48.0-nightly (8876ffc92 2020-10-02)

info: checking for self-updates
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: default toolchain set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.48.0-nightly (8876ffc92 2020-10-02)

   Compiling cfg-if v0.1.10
   Compiling libc v0.2.77
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.23
   Completed cfg-if v0.1.10 in 0.1s
   Compiling unicode-xid v0.2.1
   Completed unicode-xid v0.2.1 in 0.3s

   [...]

   Completed ghash v0.3.0 in 0.3s
   Completed thiserror v1.0.20 in 0.3s
   Compiling time-macros v0.1.1
   Completed time-macros v0.1.1 in 0.1s
   Compiling actix-threadpool v0.3.3
   Completed actix-threadpool v0.3.3 in 0.6s
   Completed v_escape v0.13.1 in 0.2s
   Completed rustls v0.18.1 in 23.0s
   Compiling postgres-protocol v0.5.2
   Completed tokio v0.2.22 in 21.3s

   [...]

   Compiling actix-session v0.4.0
   Compiling actix-files v0.3.0
   Completed actix-session v0.4.0 in 1.8s
   Completed actix-web v3.0.2 in 9.5s
   Completed actix-files v0.3.0 in 3.0s
   Compiling m4p v0.1.0 (/home/felix/Development/m4p)

      Timing report saved to /home/felix/Development/m4p/cargo-timing-20201003T102224Z.html

error: could not compile `m4p`

Caused by:
  process didn't exit successfully: `
  rustc --crate-name m4p --edition=2018 src/main.rs --error-format=json
  --json=diagnostic-rendered-ansi,artifacts --crate-type bin
  --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2
  -C metadata=22a9b879b2ed1adc -C extra-filename=-22a9b879b2ed1adc
  --out-dir /home/felix/Development/m4p/target/debug/deps
  -C incremental=/home/felix/Development/m4p/target/debug/incremental
  -L dependency=/home/felix/Development/m4p/target/debug/deps

  --extern actix_files=/home/felix/Development/m4p/target/debug/deps/libactix_files-e695f67b73f99e5b.rlib
  --extern actix_session=/home/felix/Development/m4p/target/debug/deps/libactix_session-d585b86d2d2e4a82.rlib
  --extern actix_web=/home/felix/Development/m4p/target/debug/deps/libactix_web-2a43995a0412168a.rlib
  --extern chrono=/home/felix/Development/m4p/target/debug/deps/libchrono-deca12871bfa1e40.rlib
  --extern config=/home/felix/Development/m4p/target/debug/deps/libconfig-f558148ed440ebf8.rlib
  --extern cookie=/home/felix/Development/m4p/target/debug/deps/libcookie-40ab7b95923920cb.rlib
  --extern deadpool_postgres=/home/felix/Development/m4p/target/debug/deps/libdeadpool_postgres-bec85540a48b26fa.rlib
   --extern dotenv=/home/felix/Development/m4p/target/debug/deps/libdotenv-ef265213814e1891.rlib
   --extern fast_chemail=/home/felix/Development/m4p/target/debug/deps/libfast_chemail-620b93603bf123c6.rlib
   --extern image=/home/felix/Development/m4p/target/debug/deps/libimage-940aee2557418a77.rlib
   --extern lettre=/home/felix/Development/m4p/target/debug/deps/liblettre-a4b24a82b7bb7002.rlib
   --extern mime=/home/felix/Development/m4p/target/debug/deps/libmime-8080671c8b888b7d.rlib
   --extern printpdf=/home/felix/Development/m4p/target/debug/deps/libprintpdf-19cadf9472f95c5e.rlib
   --extern rustls=/home/felix/Development/m4p/target/debug/deps/librustls-4c397a67d9bbc694.rlib
   --extern serde=/home/felix/Development/m4p/target/debug/deps/libserde-ef931f378a4039d7.rlib
   --extern serde_json=/home/felix/Development/m4p/target/debug/deps/libserde_json-7020026d8a38b1d1.rlib
   --extern sodiumoxide=/home/felix/Development/m4p/target/debug/deps/libsodiumoxide-8eb0b011062484de.rlib
   --extern tokio_pg_mapper=/home/felix/Development/m4p/target/debug/deps/libtokio_pg_mapper-d59273eae2d9cbce.rlib
   --extern tokio_pg_mapper_derive=/home/felix/Development/m4p/target/debug/deps/libtokio_pg_mapper_derive-762f0b80a1a448d4.so
   --extern tokio_postgres=/home/felix/Development/m4p/target/debug/deps/libtokio_postgres-546f30c79cce20b7.rlib
   --extern uuid=/home/felix/Development/m4p/target/debug/deps/libuuid-233c1738ad97210e.rlib

   -Ztime-passes
   -L native=/home/felix/Development/m4p/target/debug/build/ring-3974b5df818fe7df/out
   -L native=/home/felix/Development/m4p/target/debug/build/brotli-sys-4f3bb85a6c6e368e/out
   -L native=/home/felix/Development/m4p/target/debug/build/libsodium-sys-934800f85608c6c7/out/installed/lib` (signal: 9, SIGKILL: kill)

Command exited with non-zero status 101
1808.10user 93.40system 18:31.18elapsed 171%CPU (0avgtext+0avgdata 2598412maxresident)k
4701904inputs+4178376outputs (41769major+19941245minor)pagefaults 0swaps

When I open the out.txt to look at the time passes, it just ends with this:

time: 0.000; rss: 511MB	layout_testing
time: 0.011; rss: 512MB	death_checking
time: 0.003; rss: 512MB	unused_lib_feature_checking
time: 0.049; rss: 514MB	crate_lints
time: 0.025; rss: 515MB	module_lints
time: 0.074; rss: 515MB	lint_checking
time: 0.065; rss: 515MB	privacy_checking_modules
time: 0.188; rss: 515MB	misc_checking_3
time: 0.006; rss: 516MB	monomorphization_collector_root_collections

... and then it times out and crashes. I don't get a backtrace, I don't know which pass the compiler is actually hanging in, all I know so far is that it's only happening when putting the final binary together. I've attached the timing reports in the zip file. For now I can work with the 1.45.0 compiler, but it would be great if this would be fixed.

timing.zip

[jonas-schievink]

Presumably this is #75992?

[fschutt]

Well, probably. Sorry, I didn't find that issue via search. I'll watch that thread and close this issue at least until #75992 is resolved.

Thanks for notifying me of the existing issue.