rustc forever stuck compiling.

[XAMPPRocky]

Rust will essentially hang until the system kills it. Easiest way to reproduce is to build tokei with --features all. I'm on macOS, but according to both travis and appveyor it fails on Linux, and Windows.

Travis log

rustc 1.13.0 (2c6933acc 2016-11-07)
binary: rustc
commit-hash: 2c6933acc05c61e041be764cb1331f6281993f3f
commit-date: 2016-11-07
host: x86_64-apple-darwin
release: 1.13.0

[the-kenny]

I've seen a similar hang in the rustc build in nixos/nixpkgs. For us, it was src/test/run-pass/issue-36474.rs that was causing an infinite loop. Disabling the test fixed it.

[steveklabnik]

Nominating, as this seems like a regression of some kind?

[nikomatsakis]

Marking as stable-to-nightly regression, presumably...unclear if this ever worked?

[nikomatsakis]

cc @rust-lang/compiler -- anybody care to investigate?

@the-kenny @Aaronepower can either of you confirm if this is in fact a regression (i.e., did these tests ever work)?

[the-kenny]

@nikomatsakis Definitely. All our rustc-1.12.1 builds worked fine. One sample's build log. Right now we're simply deleting the file as a workaround.

If it helps I can try to reproduce the issue again to check if it stalls at the same test.

[XAMPPRocky]

@nikomatsakis Sorry for being unclear. tokei does run tests which pass without the features. However it gets stuck on build not on test. For tokei it's probably due to codegen from generating Serialize, Deserialize for JSON, CBOR, YAML, TOML. As that is the key difference from compiling without features = all. And if I do put in a syntax error, rustc will catch that and exit out as usual. It's only when the code contains no errors does this happen. The speed of the compile is probably the fault of serde-codegen, but rustc shouldn't get killed for long compile times.

[jseyfried]

@Aaronepower
The hang when building tokei with --features all appears to be #36881, triggered by this erroneous use. This issue was caused by #36573 (currently in stable) and fixed by #36882 (currently in beta). Thus, #36881 is a regression from 1.12 to 1.13, but only for code that wouldn't have compiled anyway.

@the-kenny's issue appears to be unrelated.

[nikomatsakis]

@the-kenny since the original issue appears to have been solved, I'm going to close this ticket. Can you open a new one with a bit more information to help us reproduce the problem?

[the-kenny]

Niko Matsakis <notifications@github.com> writes:

@the-kenny since the original issue appears to have been solved, I'm going to close this ticket. Can you open a new one with a bit more information to help us reproduce the problem?

Yup, no problem! I hope I'll be able to allocate some time for research into this issue today.