Expand compiler settings property

[gnidan]

Compiler settings are currently tightly coupled with solc and do not allow flexibility in what inputs are valid.

To support additional languages, as well as new compilers / new compiler options, this field should be expanded to support any meaningful data.

This would enable #55 without forcing the spec to have opinions on how it is implemented.

[fubuloubu]

👍 Vyper dev here, would definitely like to contribute on this.

[gnidan]

Glad to hear, @fubuloubu!

Since there might be some discussion warranted, some background: the spec currently defines two properties for compiler settings, namely optimize and optimize_runs.

I think the first order of business might be to decide if the spec warrants definition of properties like that specifically, to give them semantic meaning, or if the spec should be completely opaque and just define compiler settings as any object.

Thoughts?

[pipermerriam]

I'd urge us to move towards a balck box approach where any object is valid and the only structure we require is a string based identifier and settings/config (which is any object)

[gnidan]

@pipermerriam I'm of that opinion also, but wanted to see first if there was an argument to be made for specific semantics.

[fubuloubu]

If you had compiler name and version (perhaps concatenated together as a string), you could parse the options object with that information and come to the right answer to set up the compiler to replicate the result.

[fubuloubu]

I'm most interested in how the input and output of compilers is handled, so we can create a common reference frame for those activities, leveraging it for the packaging format as well as an input format to configure various tools and utilities.

[pipermerriam]

it'd be worth exploring if there is a shared format that would work for both. I think the idea of packages as compiler input is also quite interesting as it could allow compilers to generate interfaces from contract ABI or other info from the package.

[gnidan]

If you had compiler name and version (perhaps concatenated together as a string)

It's probably worth separating these? I think compile name / compiler version are two properties that are pretty universal; don't imagine we gain anything by "blackboxing" them into a single string.

create a common reference frame for those activities

I think the idea of packages as compiler input is also quite interesting as it could allow compilers to generate interfaces from contract ABI or other info from the package.

Any thoughts on what this might look like? I will give it some thought myself to see if we lay groundwork for this in Version 2 of this spec.

[pipermerriam]

So potentially something like this?

{
  name: 'solc',
  version: '1.2.3',
  settings: {<black-box>}
}

[fubuloubu]

It's probably worth separating these?

Worth discussing. There are some different verions of Solidity e.g. the emscriptin one vs. the binary one vs. the nodejs one, would those be covered under the version string or the name field? I could see the pros for both.

Any thoughts on what this might look like?

This is the fun part lol

For input, basically I was thinking about the compiler settings, and a key-value pair of contract names/paths and source code as a string, perhaps with individual settings... something along those lines.

For the output, mandatory is the compiler setup, and a key-value pair listing of the contract name and/or filepath mapping to an object that at least represents the abi/bin/runtime, and probably a few other objects like a source code to bytecode mapping (so bytecode-based tools can reference source code entries), etc. Other things could come to be useful that enable bytecode-based tools like testing infrastructure, simulation tools, formal verifiers, etc. that we need to make sure the formal spec contains.

The ethPM spec at a high level is the basic input/output of this process, so anyone can replicate on their own machines in order to verify some bytecode on Ethereum, as well as easily import community projects for use in your own projects. I've been meaning to familiarize myself more with the spec, but this has been my own personal ideas.