Support enums defined in C++ code.

[jgalenson]

This allows listing an enum in an extern "C" block as well as in the shared block. In this case, we do not emit the C++ declaration of the enum but instead emit static assertions that it has the values that we expect.

Do you know a good way to test the assertions? The ui tests don't seem to compile the generated C++ files, so I'm not sure how to do it.

I'm also considering refactoring the discriminant generation code somewhere now that it's mostly duplicated in three different places.

Closes #177.

[dtolnay]

Thank you!

I filed #188 to follow up on a test harness that is able to cover static_asserts.

[dtolnay]

The reason I didn't compute the discriminant during parsing in my original patch was to keep it as close to the source as possible. If you want to change that, we can.

I think the goal of the representation under crate::syntax::Api would be to be useful to the later compiler stages (check.rs, expand.rs + write.rs), not necessarily to be close to the source. That means normalizing all insignificant differences. For example:

• Whether the person typed fn f(&self) or fn f(self: &Ident) doesn't matter outside the parser, so those come out of the parser looking exactly the same.

• Similarly, whether they typed extern "C" { fn f(); fn g(); } or extern "C" { fn f(); } extern "C" { fn g(); } isn't significant, so those come out of the parser the same.

• I would want the same for enum E { A, B } vs enum E { A = 0, B } vs enum E { A, B = 1 } vs enum E { A = 0, B = 1 }. These are only different in ways that only matter to the parser.

[jgalenson]

That makes sense. I'll follow up with that tomorrow.