[CLI] Allow for printing output without headings (such as bytecode)

[axic]

(This issue is splitting up #8847.)

This is more of a personal preference / nit, but in builds with only one sourcefile and contract, it could be nice to skip the explaining text and filename for outputs, such the output can be used directly in other contexts or other tools, as in:

echo "contract A {uint public x;}" | solc --bin-runtime - > A.txt | evm --code $(<A.txt)

EDIT by @cameel:
One addition to the task (moved from #4617):

Consistently print the header with contract name in all cases (i.e. the ======= test.sol:C ======= part). Currently --ir, --ir-optimized, --ewasm do not print it when used on their own.

Doing this makes piping IR output more annoying so we should really to it after we have an option to disable frames.

[KukretiShubham]

Can I be assigned for this?

[cameel]

My suggestion would be to call the new option --machine-readable.

The primary goal is to make the compiler produce only the single selected artifact on stdout, without any frames, headers or any other adornment so that it can be piped to another command. The stderr should be unaffected.

Example

For example when you use solc test.sol --bin, currently you get this:

======= test.sol:C =======
Binary:
6080604052348015600f57600080fd5b50603f80601d6000396000f3fe6080604052600080fdfea2646970667358221220b742f1d41505dd2912b87c6f730d28a4d3d4929fc5cac1df9820a78ad007a18464736f6c63430008090033

With solc test.sol --bin --machine-readable it should look like this instead:

6080604052348015600f57600080fd5b50603f80601d6000396000f3fe6080604052600080fdfea2646970667358221220b742f1d41505dd2912b87c6f730d28a4d3d4929fc5cac1df9820a78ad007a18464736f6c63430008090033

Specification

• The option should affect the following other options:
  • All the options from the "Output Components" group (see solc --help)
  • --gas
  • --combined-json (but it's already printed without any frames so it's good as is)
• It cannot be used together with with:
  • --standard-json (technically we could allow it though because it does not need any frames)
  • --output-dir
  • --link (in this mode the output is always written to disk)
• Doing it for assembly mode will require [CLI] Do not ignore the output selection in assembler mode #3870. I'd say let's implement it for other modes and just keep this issue open until that PR is merged and we can add it.

Open questions

There are also some open questions we need to figure out:

• Should we allow it with multiple outputs? It probably won't be useful and would require some way to separate the outputs. I think it might be best to just require only one of the options I listed above to be specified. If there are more, print an error. We can allow it at a later time if we find a good use case.
• Same with multiple contracts - though here disallowing it could potentially make the option less useful. On the other hand, if you want to pipe the output, you probably made sure you only have a single contract so maybe that's not a problem? The most general solution would be to be able to select a contract but I think that would complicate this too much. My suggestion is for now to print an error if there is more than one contract and we'll see later if there's a need for anything more.
• Some outputs contain more than one artifact. Specifically --ewasm (both in compiler and assembly modes). My proposal would be to keep it as is but also introduce two new outputs: --ewasm-text and --ewasm-bin. Or maybe --ewasm-wasm and --ewasm-wast to match output names in Standard JSON more closely.
• What about the unlinked references that can appear in --bin? On one hand for piping having only the bytecode might be best. On the other hand, currently --link does not strictly require only bytecode so keeping them there might be fine. My suggestion would be to keep them in.

/CC @MrChico who originally proposed this in #8847. Does the above solve the original problem?

[cameel]

@KukretiShubham Are you still interested in working on this?

[KukretiShubham]

Yeah, I didn't work for much time on this issue due to prior issues. Would like to give it another shot. If anyone else have interest, they can do it.

[cameel]

Ok. In that case I'll unassign you to show it's up for the taking but let me know when you have some time and want to try to work on it again.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.