the types. Initially I thought it would be necessary to thread this data
through not only the AST but the types themselves, but then I remembered that
the pretty printer only cares about the AST. Regardless, I have elected to
leave the changes to the types intact since they will eventually be needed. I
left a few FIXMEs where it didn't seem worth finishing up since the code wasn't
crucial yet.
the types. Initially I thought it would be necessary to thread this data
through not only the AST but the types themselves, but then I remembered that
the pretty printer only cares about the AST. Regardless, I have elected to
leave the changes to the types intact since they will eventually be needed. I
left a few FIXMEs where it didn't seem worth finishing up since the code wasn't
crucial yet.
Because the json::Decoder uses the string variant name, we need a
way to correlate the string to the enum index. This passes in a
static &[&str] to read_enum_variant, which allows the json::Decoder
to know which branch it's trying to process.
I started out just removing a few instances of `HashMap` throughout rustc, but it ended up snowballing to remove the entire thing. Most uses translated to just using `@mut LinearMap` instead of `HashMap`, although I tried where possible to drop the `@mut` modifier. This ended up working out some of the time, but definitely not in the major use cases.
Things got kinda weird in some cases like:
* https://github.com/alexcrichton/rust/compare/mozilla:a56ec8c1342453a88be79e192a11501844375d40...alexcrichton:621b63300358cacad088ddd7f78180f29c40e66e#L39R1587
* https://github.com/alexcrichton/rust/compare/mozilla:a56ec8c1342453a88be79e192a11501844375d40...alexcrichton:621b63300358cacad088ddd7f78180f29c40e66e#L61R3760
* https://github.com/alexcrichton/rust/compare/mozilla:a56ec8c1342453a88be79e192a11501844375d40...alexcrichton:621b63300358cacad088ddd7f78180f29c40e66e#L71R917
* https://github.com/alexcrichton/rust/compare/mozilla:a56ec8c1342453a88be79e192a11501844375d40...alexcrichton:621b63300358cacad088ddd7f78180f29c40e66e#L91R127
I tried to tag them all with bugs which I thought would make them less weird, but I may have the wrong bug in a few places. These cases only came up when I tried to pass around `&mut LinearMap` instead of an `@mut LinearMap`.
I also ran into a few bugs when migrating to `LinearMap`, one of which is #5521. There's another set of bugs which a00d779042fb8753c716e07b4f1aac0d5ab7bf66 addresses (all marked with `XXX`). I have a feeling they're all the same bug, but all I've been able is to reproduce them. I tried to whittle down the test cases and try to get some input which causes a failure, but I've been unable to do so. All I know is that it's vaguely related to `*T` pointers being used as `&*T` (return value of `find`). I'm not able to open a very descriptive issue, but I'll do so if there seems no other better route.
I realize this is a very large pull request, so if it'd be better to split this up into multiple segments I'd be more than willing to do so. So far the tests all pass locally, although I'm sure bors will turn something up. I also don't mind keeping this up to date with rebasing. This maybe should wait until after 0.6 because it is a fairly large change...
