Channels: beta and nightly
OS: Windows (AppVeyor CI)
Caused by:
process didn't exit successfully: `rustc --crate-name dxguid C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\dxguid-sys-0.2.0\src\lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=e6ed05839a70ac27 -C extra-filename=-e6ed05839a70ac27 --out-dir C:\projects\amethyst\target\debug\deps -L dependency=C:\projects\amethyst\target\debug\deps --extern winapi=C:\projects\amethyst\target\debug\deps\libwinapi-97963d09fc19ffa3.rlib --cap-lints allow` (exit code: 3221225501)
Build failed, waiting for other jobs to finish...
error: build failed
Complete build log: https://ci.appveyor.com/project/amethyst/amethyst/build/1.0.336/job/1gg0nmj81hj67t4s
Issue did not exist in rustc 1.19.0-nightly (5f3966864 2017-05-25). Issue does exist in rustc 1.19.0-nightly (557967766 2017-05-26). https://github.com/rust-lang/rust/compare/5f3966864...557967766
Issue is that rustc is suddenly burning through a ton of memory. I had to kill it when it got to around 5GB because I don't want my computer to swap to death.
Code that is failing to compile is just a bunch of GUID constants. https://github.com/retep998/winapi-rs/blob/0.2/lib/dxguid/src/lib.rs
Doing the run with -Ztime-passes I get through the following stages without issue
time: 0.017; rss: 21MB parsing
time: 0.000; rss: 21MB recursion limit
time: 0.000; rss: 21MB crate injection
time: 0.000; rss: 21MB plugin loading
time: 0.000; rss: 21MB plugin registration
time: 0.506; rss: 85MB expansion
time: 0.000; rss: 85MB maybe building test harness
time: 0.001; rss: 85MB maybe creating a macro crate
time: 0.000; rss: 85MB checking for inline asm in case the target doesn't support it
time: 0.003; rss: 85MB early lint checks
time: 0.001; rss: 85MB AST validation
After that should come name resolution but instead it just sits around burning up memory.
Based on the commits in the commit range, I'm going to accuse @jseyfried of causing this with https://github.com/rust-lang/rust/pull/40847
Some performance testing by removing lines indicates that the time taken and memory used is roughly linear with the number of lines. Approximately 0.1 seconds and 12MB of memory per line.
Interestingly, the issue only occurs when DEFINE_GUID! is imported via #[macro_use(DEFINE_GUID)] extern crate winapi;. If I define the macro locally, then the issue goes away.
triage: P-high
ping @pnkfelix -- this seems to be of pretty high importance. I'm not sure whether @jseyfried has time to make progress on it now, maybe you can look into it a bit?
Sorry for the delay getting to this -- I worked on this yesterday and couldn't repro. I tried on a Linux and a Windows system with a couple of recent nightlies. I have some extra time this week, so once I can repro I believe I can investigate and fix within a day.
Reproduced, working on a fix now.
Fixed in #42728.
Most helpful comment
Reproduced, working on a fix now.