Glacier: a big 'ol pile of ICE

steveklabnik · 2015-10-23T13:27:51.926Z

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!

gkoz · 2015-10-23T13:29:59.209Z

Could the ICEs ever reappear?

steveklabnik · 2015-10-23T13:30:35.300Z

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

gkoz · 2015-10-23T13:31:25.048Z

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

huon · 2015-10-23T13:34:51.483Z

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

skade · 2015-10-23T13:34:56.162Z

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

gkoz · 2015-10-23T13:37:42.810Z

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?

skade · 2015-10-23T13:39:26.939Z

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

huon · 2015-10-23T13:40:24.787Z

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.

steveklabnik · 2015-10-23T14:27:19.591Z

Yes, that’s the proper thing to do.

steveklabnik · 2015-10-23T18:48:06.207Z

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

leodasvacas · 2015-10-23T19:30:06.853Z

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

emoon · 2015-10-23T20:49:46.184Z

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)

leodasvacas · 2015-10-23T21:15:10.144Z

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’.

emoon · 2015-10-23T21:16:15.499Z

Yes that sounds good. Thanks!

steveklabnik · 2015-10-23T21:20:38.722Z

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

emoon · 2015-10-23T21:35:43.085Z

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

hexsel · 2015-10-29T19:41:22.905Z

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?

steveklabnik · 2015-10-29T20:07:29.902Z

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