Add types for compiler input & output

[GrandSchtroumpf]

Feat #287

This Pull Request adds types & inline documentation for compiler input & output based on the Compiler Input & Output documentation and the ABI Spec documentation. Some types are not strictly typed (Yul AST for example) because I didn't find the right documentation. Don't hesitate to point me to some doc / code to improve it.

Note: I included a commit that demonstrates how to use the output type with the update method. I can remove the commit from the PR for separation of concern.

[coveralls]

Coverage increased (+0.1%) to 83.862% when pulling a2c0383e22b2e306055fa9312048f3d69fb9c36b on GrandSchtroumpf:type/compile into 43772326c14ab38a16bf7aca208961f5ef63c75f on ethereum:master.

[GrandSchtroumpf]

@cameel thanks for the review. I created these type for remix-plugin two years ago, I realized that some types are not well defined, I'll update it shortly. We can definitely have a script generating the types based on a version. I think this would be the best long term solution.

I think this PR could still be a good place to discuss type naming, how to deal with the different output based on the input config, ... like that we can have a base for generating types on a second step. What do you think ?

[cameel]

We can definitely have a script generating the types based on a version.

The problem here is that it's a lot of work to get that right for all the versions. Unfortunately currently this is basically defined by the implementation of the C++ compiler and not some more generic spec. Docs cover it on a high level but small details would have to be checked in the source.

My general feeling is that it would be easier to get some kind of schema into the main compiler repo first and get this working for the current version. Then worry about older ones later. The downside is that this way the typing for older versions would be unavailable or wrong for the time being.

On the other hand having precise definitions for all versions would definitely be appreciated by people working on tooling so there is some value in that if we could pull that off. This is far from our current roadmap though so I can't promise that we could focus on that enough to get that through. As is, the current Typescript migration is already progressing much slower than it otherwise could because we're bottlenecked by people available to review the PRs.

I think this PR could still be a good place to discuss type naming, how to deal with the different output based on the input config, ... like that we can have a base for generating types on a second step. What do you think ?

Maybe. But I really don't want you to put too much extra work into something that would end up being rejected so I think it would be best to start with some general discussion first, before focusing on details. I can definitely give you some feedback here but I'm not sure how much this will matter if in the end it turns out it's not the solution we want.

Also @axic will definitely have some opinions here, so we should also wait for some input from him :)

[GrandSchtroumpf]

Ok no problem. I can continue the output types on an external library for now, and if you consider it would make sense to add it into solc-js at some point I can make another PR 🙂