Add doc comments everywhere

[cpcloud]

Closes #36

[cpcloud]

@magnet Also could use your review.

[lovesegfault]

Looks good, but now I'm starting to think about how to maintain a large number of tests of the kind sample_fb -> expected (code|ast). I'm not sure how rustc does this, maybe @nagisa could weigh in.

[magnet]

LGTM overall!

One thing that may be worth looking into is forwarding the comments to the IR layer when adding it to new types (e.g EnumVal)

[cpcloud]

One thing that may be worth looking into is forwarding the comments to the IR layer when adding it to new types (e.g EnumVal)

Ah yeah, let me do that.

[nagisa]

I'm starting to think about how to maintain a large number of tests of the kind sample_fb -> expected (code|ast). I'm not sure how rustc does this,

Tests for distinct output families are different tests, so it makes all the sense for them to be separate tests in the first place. rustc only reuses the same test for testing different auxiliary inputs (such as… architecture, flags, etc.) and so does butte – by construction.

[magnet]

I'm starting to think about how to maintain a large number of tests of the kind sample_fb -> expected (code|ast). I'm not sure how rustc does this,

I'd like to add even more of these, e.g fb -> Rust code (using quote!()). These would likely be in codegen.rs and help make sure we don't accidentally break things.

We're getting larger and larger modules & would be happy splitting things up a bit, while keeping tests within modules. Opinions welcome 🙂

[cpcloud]

After tinkering some more with flatc to see what it generates I don't think it makes sense to generate comments for attribute or root_type statements (we still need to accept them in the parser though). file_identifier and file_extension make sense, since they are generated consts.

[cpcloud]

For namespaces I've created #44 since it's a fair amount of code and should be reviewed separately.

[cpcloud]

@magnet @lovesegfault This could use another round of review, as I've done some refactoring.