Nightly compilation is infinite (2018-03-15)

[pravic]

nightly-x86_64-pc-windows-msvc updated - rustc 1.26.0-nightly (3926453 2018-03-15)
$ cargo +nightly install -f clippy
Installing clippy v0.0.187
…

After a while I have noticed that compilation wasn't going to stop. And I see 3 rustc processes with

rustc.exe --crate-name unicode_normalization
rustc.exe --crate-name regex_syntax [...] \regex-syntax-0.4.2
rustc.exe --crate-name regex_syntax [...] \regex-syntax-0.5.3

However, after 15 minutes I saw one more process with

rustc.exe --crate-name idna

And 9 minutes after there was another process. So, it looks like compilation is not infinite per se, it just tooks way more time to finish. (P.S. It took 28 minutes to fall with "can't find crate for rustc_const_eval").

For example, rustc has the following stack of a thread that burns CPU:

dbghelp.dll!StackWalk+0x1bd
rustc-a5a7a6b4bef6f752.dll!_rust_shrink_in_place+0x965
rustc-a5a7a6b4bef6f752.dll!ZN9backtrace7capture9Backtrace14new_unresolved17h581edff5de2a963eE+0x2e
rustc-a5a7a6b4bef6f752.dll!ZN162_$LT$rustc..mir..interpret..error..EvalError$LT$$u27$tcx$GT$$u20$as$u20$core..convert..From$LT$rustc..mir..interpret..error..EvalErrorKind$LT$$u27$tcx$GT$$GT$$GT$4from17h1a9a03dd1f37cf69E+0x7e
rustc_mir-2fcc0a27e76d8b8d.dll!ZN9rustc_mir9interpret5place5Place15elem_ty_and_len17h2932d87ba381b64cE+0x1faf
rustc_mir-2fcc0a27e76d8b8d.dll!ZN111_$LT$rustc_mir..interpret..eval_context..EvalContext$LT$$u27$a$C$$u20$$u27$mir$C$$u20$$u27$tcx$C$$u20$M$GT$$GT$16push_stack_frame27collect_storage_annotations17hf30764fbfef5eab0E+0x37a0
rustc_mir-2fcc0a27e76d8b8d.dll!ZN9rustc_mir9interpret6memory16read_target_uint17h942d157f99676200E+0x3d36
rustc_mir-2fcc0a27e76d8b8d.dll!ZN9rustc_mir9interpret10const_eval9eval_body17hf12e2fd1d2a07104E+0xbeb
rustc_mir-2fcc0a27e76d8b8d.dll!ZN9rustc_mir9interpret10const_eval19const_eval_provider17haddfcc721ac41af1E+0x14d
rustc-a5a7a6b4bef6f752.dll!ZN5rustc9dep_graph5graph8DepGraph14assert_ignored17h73bd16e03e5a75b9E+0x1f158
rustc-a5a7a6b4bef6f752.dll!ZN5rustc2ty4maps70_$LT$impl$u20$rustc..ty..maps..queries..const_eval$LT$$u27$tcx$GT$$GT$6ensure17hdeebcef5b5a77385E+0x5dd
rustc-a5a7a6b4bef6f752.dll!ZN5rustc2ty4maps70_$LT$impl$u20$rustc..ty..maps..queries..const_eval$LT$$u27$tcx$GT$$GT$7try_get17h4aa4426196ce4e7eE+0x96f
rustc-a5a7a6b4bef6f752.dll!ZN5rustc2ty4maps8TyCtxtAt10const_eval17h3e5e280b38a356d2E+0x77
rustc_mir-2fcc0a27e76d8b8d.dll!ZN111_$LT$rustc_mir..interpret..eval_context..EvalContext$LT$$u27$a$C$$u20$$u27$mir$C$$u20$$u27$tcx$C$$u20$M$GT$$GT$16push_stack_frame27collect_storage_annotations17hf30764fbfef5eab0E+0x72cd
rustc_mir-2fcc0a27e76d8b8d.dll!ZN111_$LT$rustc_mir..interpret..eval_context..EvalContext$LT$$u27$a$C$$u20$$u27$mir$C$$u20$$u27$tcx$C$$u20$M$GT$$GT$16push_stack_frame27collect_storage_annotations17hf30764fbfef5eab0E+0x7074
rustc_mir-2fcc0a27e76d8b8d.dll!ZN111_$LT$rustc_mir..interpret..eval_context..EvalContext$LT$$u27$a$C$$u20$$u27$mir$C$$u20$$u27$tcx$C$$u20$M$GT$$GT$16push_stack_frame27collect_storage_annotations17hf30764fbfef5eab0E+0x6464
rustc_mir-2fcc0a27e76d8b8d.dll!ZN111_$LT$rustc_mir..interpret..eval_context..EvalContext$LT$$u27$a$C$$u20$$u27$mir$C$$u20$$u27$tcx$C$$u20$M$GT$$GT$16push_stack_frame27collect_storage_annotations17hf30764fbfef5eab0E+0x35d0
rustc_mir-2fcc0a27e76d8b8d.dll!ZN9rustc_mir9interpret6memory16read_target_uint17h942d157f99676200E+0x3d36

[michaelwoerister]

cc @oli-obk @eddyb

[michaelwoerister]

Thanks for the bug report, @pravic!

[mati865]

Strangely enough looks like it happens only on Windows (both msvc and gnu).

[oli-obk]

P.S. It took 28 minutes to fall with "can't find crate for rustc_const_eval"

Just to clarify: building the dependencies for the crate failing with the above error took 28 minutes. The final crate errors immediately. So it's not const eval related just because it mentions rustc_const_eval.

It is const eval related though ;) And the issue is most likely backtrace generation. Is it possible generating backtraces takes a long time on windows? Every const eval error generates a backtrace. I think we can safely assume noone needs those except for someone debugging miri. The backtraces are also an issue for FreeBSD.

I don't want to remove them because they are super helpful for miri debugging, but since they obviously have a negative effect, I'll add a check to only generate them if explicitly requested.

[nikomatsakis]

triage: P-high