("ICE" stands for "internal compiler error" in Rust-land... just a bit of '90s humor there.)
Today: not such a great productivity day either. Bug triage, so I turned all the remaining TODOs in the code into FIXMEs with issue numbers. I love when I can delete a "FIXME [when feature X works]" altogether because I know that feature X does work now and I can change the code to use it! In this case, it was a very simple change: changing a class in the parser to have an empty destructor to enforce that the type is non-copyable. This is kind of a hack, since we don't have an explicit way to say that a class should be non-copyable (the rules are that a class is non-copyable if it has a destructor; has one or more non-copyable fields; or both), but it seems like a pretty benign hack.
In case you're wondering about the "non-copyable" business, Rust classifies types into kinds, like many typed languages, but unusually, one of the kinds is the "copyable" kind. That lets us write type-parameterized functions that can be boundedly parameterized over only types such that values in that type are allowed to be copied. In case you're wondering why that matters, Brian explained it pretty extensively on the mailing list today.
Then I shifted into fixing bugs, or trying to, and narrowed down issue 2771 a bit. Looks like the interaction between intrinsics, inlining, and the little-used "list metadata" command is not going too well, as the metadata parser is failing to find a descriptor in a side table for one of the entries. That entry happens to be for a compiler-generated built-in function that's marked inlineable. I'm not sure whether the right thing is to not print out anything about those functions (since they were introduced by the compiler), or for the metadata pretty-printer to generate all the information the parser needs.