Solidity: Support JSON ABI interface imports

[axic]

Syntax: interface <InterfareName> from <fileName>;

Standard-json should have a file type field (see ethpm 3 for that) so that json is not parsed as solidity.

Another solution might be to just skip files that look like json and only error if they are imported as solidity or requested via output selection.

---

The main goal is to create a separation of interface specification from Solidity syntax and versions.

Depends on #847.

Using the interface contract, we could have a special case: interface <Name> as <JSON ABI>.

interface Token as '[{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[{"name":"success","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"totalSupply","outputs":[{"name":"supply","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_from","type":"address"},{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transferFrom","outputs":[{"name":"success","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"}],"name":"balanceOf","outputs":[{"name":"balance","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transfer","outputs":[{"name":"success","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"},{"name":"_spender","type":"address"}],"name":"allowance","outputs":[{"name":"remaining","type":"uint256"}],"payable":false,"type":"function"},{"anonymous":false,"inputs":[{"indexed":true,"name":"_from","type":"address"},{"indexed":true,"name":"_to","type":"address"},{"indexed":false,"name":"_value","type":"uint256"}],"name":"Transfer","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"_owner","type":"address"},{"indexed":true,"name":"_spender","type":"address"},{"indexed":false,"name":"_value","type":"uint256"}],"name":"Approval","type":"event"}]';

The ABI would be passed as a StringLiteral.

Optionally/additionally we could have a new section in the compiler JSON input section to define such an interface contract:

interfaces: {
  "<Name>": "[{\"name\":\"transfer\"....]"
}

This would also need to be stored in the metadata.

[chriseth]

What is the benefit of exposing the json abi like that? Currently, the JSON-ABI is a layer completely unrelated to Solidity as a language, and I think these kinds of separations are a good thing. Solidity interfaces are also much stricter than just the ABI.

[chriseth]

This came up again at devcon, so I'm putting it on the agenda.

[axic]

Solidity interfaces are also much stricter than just the ABI.

It would be a good goal to have parity in strictness.

[chriseth]

interface I from '...'?

[axic]

Sounds good.

[chriseth]

@erak suggested that it might be cleaner to import from json files instead.

[erak]

I think the main question is, if people need the Solidity source as an artifact or not. If they do, I'd suggest either using a tool that is capable of generating the source from the JSON ABI, and passing this as a usual input file to the compiler.

But if they don't, adding a command line option e.g. solc --import-json-abi "<json-string>", which would request generation of Solidity code from that and add it to the list of source codes to compile.

Referencing this chunk of code from the source file that imports this would need to be decided on, though.

[leonardoalt]

From call: people seem to like the interface passed via standard-json where the name is visible in the source code via
import Name from NameJSON;

[chriseth]

If we do that, we need to distinguish between solidity files and json abi files, i.e. files that are to be compiled and files that the compiler only looks at when requested.

[axic]

In the standard JSON source files are an object and have content, hash, etc. fields already. We could consider adding a new one, kind, which if omitted, defaults to Solidity (in case the language is set to Solidity).

[rumkin]

It's also reasonable to make json files be importable as ABI in such way:

interface Token from './erc20.json'

And for JSON files with custom structure it's possible to define a path inside of JSON:

interface Token from './erc20.json#contracts[0].abi'

Where ./erc.json is a path to ABI file and #contracts[0].abi is a path inside of JSON object.

[chriseth]

This is now pending standardization by the "EthPM Committee", I fear...

@njgheorghita

[ekpyron]

Related https://github.com/ethereum/solidity/issues/8081

[WyseNynja]

What is the benefit of exposing the json abi like that? Currently, the JSON-ABI is a layer completely unrelated to Solidity as a language, and I think these kinds of separations are a good thing. Solidity interfaces are also much stricter than just the ABI.

I want this feature because I want to be able to just copy/paste some JSON from etherscan and be able to interact with the contract. I don't have the source, or the source is in a different version and ensuring I get the identical compilation that mainnet has sounds like a place for bugs to slip in.

[chriseth]

Unfortunately, this turned out to be too complicated because of structs in interfaces.

[gnidan]

I developed an alternative solution: abi-to-sol, which allows you to generate interface files from a given JSON ABI