Glacier: a big 'ol pile of ICE


#1

One easy way to help out on an open source project is to check if a bug still reproduces. There’s one kind of bug that’s very special to Rust: the ICE. Internal Compiler Errors are especially weird, since a refactoring can sometimes fix them. And we have 200 ICEs: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-ICE

As such, I’ve made a repository: https://github.com/steveklabnik/glacier

Basically, there’s a src directory, with one file per ICE. A small Bash script loops over all the files, ensuring that they cause an ICE. If any of them don’t, the build fails. I’ve set the repo up with Travis and Nightli.es, so we’ll test each ICE once per day.

I’ve added two ICEs to start, but since this is a fairly easy way to contribute to a project, I haven’t done more. If you’re new to open source, please drop by and give me a hand!


#2

Could the ICEs ever reappear?


#3

In theory, yeah. We still just close the issue, and re-open if someone else notices it come back.


#4

I mean, as long as you’re collecting the test cases might as well check for regressions too? :wink:


#5

Patches to rustc that fix an ICE will also include a regression test or two (usually).


#6

Shouldn’t that be covered by a compilation test after fixing?


#7

The premise seems to be that sometimes bugs are fixed because of unrelated work. I’m not sure, do the regression tests still get added in such cases?


#8

In that case, you can close the issue by adding a regression test.


#9

Issues are often tagged with E-needstest when someone notices they seem to be fixed (and then someone else might pick half a dozen of those issues and submit a PR with their tests to close them). I suspect that this was the approach @steveklabnik was intending to take when glacier detects something is resolved.


#10

Yes, that’s the proper thing to do.


#11

We’ve found our first one! https://github.com/steveklabnik/glacier/pull/11


#12

Awesome! Triaging ICE is a nice way to pass time.


#13

So what’s the appropriate steps to take if one finds an issue in that list that doesn’t ICE anymore? (this https://github.com/rust-lang/rust/issues/27895 doesn’t ICE for me on 1.4.0 beta 3)


#14

I think it’s sufficient to comment in the issue that it no longer ICEs, someone will see that and either close or label as ‘needs test’.


#15

Yes that sounds good. Thanks!


#16

Leave a comment and I will take appropriate action (re-tagging and checking it off the list)


#17

Thanks! I have made a bunch of PR:s for you now also :slight_smile:


#18

So, just out of curiosity, why only ICEs? Why not all bugs that have testable code that should compile but doesn’t or does it in the wrong way?


#19

Sure! That seems useful as well. It’s nice to have focus on a project, so i’m just starting with one thing.