ICEs with incremental compilation building glium

[nikomatsakis]

@jonas-schievink writes in #34956:

I just tried to build glium with this and I'm hitting multiple ICEs about local/foreign items:
https://gist.github.com/jonas-schievink/536a1ad7aa065193e4954242c9885cbd
(I've set RUSTFLAGS=-Zincremental=target/INCREMENTAL before running cargo)

[jonas-schievink]

This happens on stable too, btw

[michaelwoerister]

This happens on stable too, btw

You mean, if you specify -Zincremental on stable?

[jonas-schievink]

@michaelwoerister Yes

[nikomatsakis]

So I did some digging. There are a few bugs I think.

One of them occurs is you run with -j1 -v, in which case you get an error in the SVH code at src/librustc_incremental/calculate_svh.rs:94, where we call expect_item, but sometimes the def-id corresponds to a foreign-item.

There seems to be a distinct bug that occurs with the default amount of parallelism which (I think) must relate to reading the wrong files or something like that. Still investigating.

[nikomatsakis]

Fixing the problem with expect_item was easy. I am now investigating the second failure. Seems to be that when processing xml-rs we create an invalid read from a foreign HIR node, labeled as <std::vec::Vec<T> as std::ops::Drop>. I'm not 100% sure yet where this occurs but I guess sometime in trans?

[nikomatsakis]

OK, the other problem goes away with -Z orbit, and is due to how "old trans" handles inlined functions.

[michaelwoerister]

Have you tried turning backtraces on? That should give you idea where it occurs.

On July 26, 2016 8:44:31 PM GMT+02:00, Niko Matsakis notifications@github.com wrote:

Fixing the problem with expect_item was easy. I am now investigating
the second failure. Seems to be that when processing xml-rs we create
an invalid read from a foreign HIR node, labeled as <std::vec::Vec<T> as std::ops::Drop>. I'm not 100% sure yet where this occurs but I
guess sometime in trans?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#34991 (comment)

[nikomatsakis]

Actually, I still get an ICE even with -Z orbit, but it occurs later. It seems to all be connected to register_reads, which seems a bit suspicious to me now that I look at it a bit more closely. I'm actually not sure if it's even needed, to be honest. It seems like the "trans item" is just a def-id and substs, so I would expect we should just start a suitable task and whatever reads are needed will be generated automatically (for example, if we use the def-id to fetch the MIR for an item, that should generate a read from the table where the MIR is stored; if the MIR has to be loaded from meta-data, it should generate a read from the metadata, etc).

[nikomatsakis]

Maybe @michaelwoerister we should touch base on the whole scheme here to make sure we've got it all setup right? Doesn't feel like trans needs to be particularly special.

[nikomatsakis]

Making progress here. I've eliminated a few sources of ICEs, but still have a problem left. I may post an intermediate PR, or may press on. :)

[nikomatsakis]

OK, so I have all the ICEs fixed. I'm encountering a bit of trouble because cargo is using the same crate name / disambiguator (build-script-build / ``) for every build.rs file, so unless you use-j1 we run into #32754.

Only problem is that I have no test cases: most of these ICEs arise from multi-crate scenarios and I didn't bother to reduce them. Probably should do so before opening a PR.

[nikomatsakis]

One other problem: running, then using cargo clean and running again, doesn't seem to save much time. :( Will have to see what's causing it not to reuse results. Probably better to start with a very simple crate though. :)