Using the Compiler

.. index:: ! commandline compiler, compiler;commandline, ! solc

Using the Commandline Compiler

Note

This section does not apply to :ref:`solcjs <solcjs>`, not even if it is used in commandline mode.

Basic Usage

One of the build targets of the Solidity repository is solc, the Solidity commandline compiler. Using solc --help provides you with an explanation of all options. The compiler can produce various outputs, ranging from simple binaries and assembly over an abstract syntax tree (parse tree) to estimations of gas usage. If you only want to compile a single file, you run it as solc --bin sourceFile.sol and it will print the binary. If you want to get some of the more advanced output variants of solc, it is probably better to tell it to output everything to separate files using solc -o outputDirectory --bin --ast-compact-json --asm sourceFile.sol.

Optimizer Options

Before you deploy your contract, activate the optimizer when compiling using solc --optimize --bin sourceFile.sol. By default, the optimizer will optimize the contract assuming it is called 200 times across its lifetime (more specifically, it assumes each opcode is executed around 200 times). If you want the initial contract deployment to be cheaper and the later function executions to be more expensive, set it to --optimize-runs=1. If you expect many transactions and do not care for higher deployment cost and output size, set --optimize-runs to a high number. This parameter has effects on the following (this might change in the future):

the size of the binary search in the function dispatch routine
the way constants like large numbers or strings are stored

.. index:: allowed paths, --allow-paths, base path, --base-path, include paths, --include-path

Base Path and Import Remapping

The commandline compiler will automatically read imported files from the filesystem, but it is also possible to provide :ref:`path redirects <import-remapping>` using prefix=path in the following way:

solc github.com/ethereum/dapp-bin/=/usr/local/lib/dapp-bin/ file.sol

This essentially instructs the compiler to search for anything starting with github.com/ethereum/dapp-bin/ under /usr/local/lib/dapp-bin.

When accessing the filesystem to search for imports, :ref:`paths that do not start with ./ or ../ <direct-imports>` are treated as relative to the directories specified using --base-path and --include-path options (or the current working directory if base path is not specified). Furthermore, the part of the path added via these options will not appear in the contract metadata.

For security reasons the compiler has :ref:`restrictions on what directories it can access <allowed-paths>`. Directories of source files specified on the command-line and target paths of remappings are automatically allowed to be accessed by the file reader, but everything else is rejected by default. Additional paths (and their subdirectories) can be allowed via the --allow-paths /sample/path,/another/sample/path switch. Everything inside the path specified via --base-path is always allowed.

The above is only a simplification of how the compiler handles import paths. For a detailed explanation with examples and discussion of corner cases please refer to the section on :ref:`path resolution <path-resolution>`.

.. index:: ! linker, ! --link, ! --libraries

Library Linking

If your contracts use :ref:`libraries <libraries>`, you will notice that the bytecode contains substrings of the form __$53aea86b7d70b31448b230b20ae141a537$__ (format was different <v0.5.0). These are placeholders for the actual library addresses. The placeholder is a 34 character prefix of the hex encoding of the keccak256 hash of the fully qualified library name. The bytecode file will also contain lines of the form // <placeholder> -> <fq library name> at the end to help identify which libraries the placeholders represent. Note that the fully qualified library name is the path of its source file and the library name separated by :. You can use solc as a linker meaning that it will insert the library addresses for you at those points:

Either add --libraries "file.sol:Math=0x1234567890123456789012345678901234567890 file.sol:Heap=0xabCD567890123456789012345678901234567890" to your command to provide an address for each library (use commas or spaces as separators) or store the string in a file (one library per line) and run solc using --libraries fileName.

Note

Starting Solidity 0.8.1 accepts = as separator between library and address, and : as a separator is deprecated. It will be removed in the future. Currently --libraries "file.sol:Math:0x1234567890123456789012345678901234567890 file.sol:Heap:0xabCD567890123456789012345678901234567890" will work too.

.. index:: --standard-json, --base-path

If solc is called with the option --standard-json, it will expect a JSON input (as explained below) on the standard input, and return a JSON output on the standard output. This is the recommended interface for more complex and especially automated uses. The process will always terminate in a "success" state and report any errors via the JSON output. The option --base-path is also processed in standard-json mode.

If solc is called with the option --link, all input files are interpreted to be unlinked binaries (hex-encoded) in the __$53aea86b7d70b31448b230b20ae141a537$__-format given above and are linked in-place (if the input is read from stdin, it is written to stdout). All options except --libraries are ignored (including -o) in this case.

Warning

Manually linking libraries on the generated bytecode is discouraged because it does not update contract metadata. Since metadata contains a list of libraries specified at the time of compilation and bytecode contains a metadata hash, you will get different binaries, depending on when linking is performed.

You should ask the compiler to link the libraries at the time a contract is compiled by either using the --libraries option of solc or the libraries key if you use the standard-JSON interface to the compiler.

Note

The library placeholder used to be the fully qualified name of the library itself instead of the hash of it. This format is still supported by solc --link but the compiler will no longer output it. This change was made to reduce the likelihood of a collision between libraries, since only the first 36 characters of the fully qualified library name could be used.

.. index:: ! EVM version, compile target

Setting the EVM Version to Target

When you compile your contract code you can specify the Ethereum virtual machine version to compile for to avoid particular features or behaviors.

Warning

Compiling for the wrong EVM version can result in wrong, strange and failing behavior. Please ensure, especially if running a private chain, that you use matching EVM versions.

On the command-line, you can select the EVM version as follows:

solc --evm-version <VERSION> contract.sol

In the :ref:`standard JSON interface <compiler-api>`, use the "evmVersion" key in the "settings" field:

{
  "sources": {/* ... */},
  "settings": {
    "optimizer": {/* ... */},
    "evmVersion": "<VERSION>"
  }
}

Target Options

Below is a list of target EVM versions and the compiler-relevant changes introduced at each version. Backward compatibility is not guaranteed between each version.

homestead (support deprecated)
- (oldest version)
tangerineWhistle (support deprecated)
- Gas cost for access to other accounts increased, relevant for gas estimation and the optimizer.
- All gas sent by default for external calls, previously a certain amount had to be retained.
spuriousDragon (support deprecated)
- Gas cost for the exp opcode increased, relevant for gas estimation and the optimizer.
byzantium (support deprecated)
- Opcodes returndatacopy, returndatasize and staticcall are available in assembly.
- The staticcall opcode is used when calling non-library view or pure functions, which prevents the functions from modifying state at the EVM level, i.e., even applies when you use invalid type conversions.
- It is possible to access dynamic data returned from function calls.
- revert opcode introduced, which means that revert() will not waste gas.
constantinople
- Opcodes create2, extcodehash, shl, shr and sar are available in assembly.
- Shifting operators use shifting opcodes and thus need less gas.
petersburg
- The compiler behaves the same way as with constantinople.
istanbul
- Opcodes chainid and selfbalance are available in assembly.
berlin
- Gas costs for SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT increased. The compiler assumes cold gas costs for such operations. This is relevant for gas estimation and the optimizer.
london
- The block's base fee (EIP-3198 and EIP-1559) can be accessed via the global block.basefee or basefee() in inline assembly.
paris
- Introduces prevrandao() and block.prevrandao, and changes the semantics of the now deprecated block.difficulty, disallowing difficulty() in inline assembly (see EIP-4399).
shanghai
- Smaller code size and gas savings due to the introduction of push0 (see EIP-3855).
cancun
- The block's blob base fee (EIP-7516 and EIP-4844) can be accessed via the global block.blobbasefee or blobbasefee() in inline assembly.
- Introduces blobhash() in inline assembly and a corresponding global function to retrieve versioned hashes of blobs associated with the transaction (see EIP-4844).
- Opcode mcopy is available in assembly (see EIP-5656).
- Opcodes tstore and tload are available in assembly (see EIP-1153).
prague
osaka (default)
- clz builtin function is available in inline assembly. (EIP-7939)

.. index:: ! standard JSON, ! --standard-json

Compiler Input and Output JSON Description

The recommended way to interface with the Solidity compiler especially for more complex and automated setups is the so-called JSON-input-output interface. The same interface is provided by all distributions of the compiler.

The fields are generally subject to change, some are optional (as noted), but we try to only make backwards compatible changes.

The compiler API expects a JSON formatted input and outputs the compilation result in a JSON formatted output. The standard error output is not used and the process will always terminate in a "success" state, even if there were errors. Errors are always reported as part of the JSON output.

The following subsections describe the layout and explain each field and object of the format.

Input Description

The root JSON object contains three top level keys that define the compilation process.

Field	Type	Required	Description
`language`	string	Yes	Source code language. Supported values: `"Solidity"`, `"Yul"`, `"SolidityAST"` (experimental), `"EVMAssembly"` (experimental).
`sources`	object	Yes	Map of source file names to their content or URL references.
`settings`	object	No	Compiler configuration including optimizer, EVM version, output selection, among others.

Sources

The sources object is a map where each key is the global name of a source file. Imports can use other files via remappings (see below). Each value is a source descriptor object with the following fields.

keccak256

Optional. Keccak-256 hash of the source file content. It is used to verify the retrieved content if imported via URLs.

urls

URL(s) to the source file. Required unless content is used URL(s) should be imported in this order and the result checked against the keccak256 hash (if available). If the hash doesn't match or none of the URL(s) result in success, an error should be raised. Using the commandline interface only filesystem paths are supported. With the JavaScript interface the URL will be passed to the user-supplied read callback, so any URL supported by the callback can be used. If files are used, their directories should be added to the command-line via --allow-paths <path>.

ast

Required if language is set to "SolidityAST". If language is set to "SolidityAST", an AST needs to be supplied under the "ast" key and there can be only one source file present. The format is the same as used by the ast output. Note that importing ASTs is experimental and in particular that: - importing invalid ASTs can produce undefined results and - no proper error reporting is available on invalid ASTs.

Furthermore, note that the AST import only consumes the fields of the AST as produced by the compiler in "stopAfter": "parsing" mode and then re-performs analysis, so any analysis-based annotations of the AST are ignored upon import.

assemblyJson

Required if language is set to "EVMAssembly". If language is set to "EVMAssembly", an EVM Assembly JSON object needs to be supplied under the "assemblyJson" key and there can be only one source file present. The format is the same as used by the evm.legacyAssembly output or --asm-json output on the command line. Note that importing EVM assembly is experimental.

TODO: ".data": { ... }, // optional "sourceList": [ ... ] // optional (if no source node was defined in any .code object)

Note

For Solidity and Yul languages, each source must provide either urls or content. For SolidityAST, the ast field replaces both. For EVMAssembly, the assemblyJson field is used instead.

Settings

The settings object defines general configuration of the compilation pipeline, such as the EVM version and enabling the IR pipeline, and also specific configuration for the optimizer, debug, metadata, libraries and output selection. Every field within settings is optional and in case they are omitted, the compiler uses default values.

General Settings

Field	Type	Description
`stopAfter`	string	Stop compilation after the given stage. Currently only `"parsing"` is valid.
`remappings`	string[]	List of remappings.
`experimental`	boolean	Experimental mode toggle, false by default. Makes it possible to use experimental features (but does not enable any such feature by itself). The use of this mode is recorded in contract metadata.
`evmVersion`	string	Version of the EVM to compile for. Affects type checking and code generation. Can be `homestead`, `tangerineWhistle`, `spuriousDragon`, `byzantium`, `constantinople`, `petersburg`, `istanbul`, `berlin`, `london`, `paris`, `shanghai`, `cancun`, `prague` or `osaka` (default).
`eofVersion`	integer	Experimental. EVM Object Format version to compile for. Currently the only valid value is `1`. If not specified, legacy non-EOF bytecode will be generated. Requires `evmVersion` >= `osaka`.
`viaIR`	boolean	Change compilation pipeline to go through the Yul intermediate representation. False by default.
`viaSSACFG`	boolean	Experimental. Turn on SSA CFG-based code generation via the IR (implies `viaIR: true`). False by default.

Optimizer Settings

The optimizer object controls how aggressively the compiler optimizes the generated bytecode. As mentioned before, all settings are optional and have default values. The optimizer can be turned on by a top level toggle field, optimizer.enabled, which is false by default.

Note

The state of the optimizer is fully determined by the 'details' dict and this setting only affects its defaults - when enabled, all components default to being enabled. The opposite is not true - there are several components that always default to being enabled an can only be explicitly disabled via 'details'.

Warning

Before version 0.8.6 omitting this setting was not equivalent to setting it to false and would result in all components being disabled instead.

Warning

Enabling optimizations for EVMAssembly input is allowed but not necessary under normal circumstances. It forces the opcode-based optimizer to run again and can produce bytecode that is not reproducible from metadata.

The integer field optimizer.runs indicates how many times the code is intended to run. This field is optional and defaults to a value of 200. Lower values will optimize more for initial deployment cost, higher values will optimize more for high-frequency usage.

The optimizer.details object provides fine-grained control over individual optimizer components. The default values are determined by whether the optimizer is enabled or not.

Note

The optimizer.enabled setting only affects the defaults of optimizer.details and has no effect when all values are provided explicitly.

Each component can be enabled using the following boolean fields:

Field	Default	Description
`peephole`	True	Peephole optimizer (opcode-based). Always run, even with optimization disabled, except for EVMAssembly input or when explicitly turned off.
`inliner`	True	Inliner (opcode-based).
`jumpdestRemover`	True	Unused `JUMPDEST` remover (opcode-based). Always runs, even with optimization disabled, except for EVMAssembly input or when explicitly turned off.
`orderLiterals`	True	Literal reordering (codegen-based). Moves literals to the right of commutative binary operators during code generation, helping exploit associativity.
`deduplicate`	True	Block deduplicator (opcode-based). Unifies assembly code blocks that share content.
`cse`	True	Common subexpression elimination (opcode-based). This is the most complicated step but can also provide the largest gain.
`constantOptimizer`	True	Constant optimizer (opcode-based). Tries to find better representations of literal numbers and strings, that satisfy the size/cost trade-off determined by the `runs` setting.
`simpleCounterForLoopUncheckedIncrement`	True	Unchecked loop increment (codegen-based). Use unchecked arithmetic when incrementing the counter of `for` loops under certain circumstances. Always runs, even with optimization disabled, unless explicitly turned off.
`yul`	True	Yul optimizer. Used to optimize the IR produced by the Yul IR-based pipeline as well as inline assembly and utility Yul code generated by the compiler. Before Solidity 0.6.0 the default was `false`.

There is also the optimizer.yulDetails subobject which contains fine tuning options for the Yul optimizer. The optimizer.yulDetails.stackAllocation setting aims to improve allocation of stack slots for variables and can free up stack slots early. The optimizer.yulDetails.optimizerSteps is the most important setting of the Yul optimizer, defining its optimization step sequence. The general form of the value is "<main sequence>:<cleanup sequence>". The setting is optional and when omitted, default values are used for both sequences. If the value does not contain the : delimiter, it is interpreted as the main sequence and the default is used for the cleanup sequence. To make one of the sequences empty, the delimiter must be present at the first or last position. In particular if the whole value consists only of the delimiter, both sequences are empty. Note that there are several hard-coded steps that always run, even when both sequences are empty. For more information see :ref:`Selecting Optimizations <selecting-optimizations>`.

Debug Settings

The debug object controls how revert and require reason strings and debug annotations are handled in the output.

The debug.revertStrings field defines how to treat revert and require reason strings. Settings are:

"default": does not inject compiler-generated revert strings and keeps user-supplied ones.
"strip": removes all revert strings keeping side-effects
"debug": injects strings for compiler-generated internal reverts, implemented for ABI encoders V1 and V2 for now.
"verboseDebug": even appends further information to user-supplied revert strings (not yet implemented).

The debug.debugInfo field defines how much extra debug information to include in comments in the producedEVM assembly and Yul code. Available components are:

location: Annotations of the form @src <index>:<start>:<end> indicating the location of the corresponding element in the original Solidity file, where:
- <index> is the file index matching the @use-src annotation,
- <start> is the index of the first byte at that location,
- <end> is the index of the first byte after that location.
snippet: A single-line code snippet from the location indicated by @src. The snippet is quoted and follows the corresponding @src annotation.
ast-id: Annotations of the form @ast-id <id> over elements that can be mapped back to a definition in the original Solidity file. <id> is a node ID in the Solidity AST ('ast' output).
ethdebug: Ethdebug annotations (experimental).
*: Wildcard value that can be used to request all non-experimental components.

Metadata Settings

The metadata object configures how contract metadata is embedded in the compiled bytecode.

Field	Type	Default	Description
`appendCBOR`	boolean	True	The CBOR metadata is appended at the end of the bytecode by default. Setting this to false omits the metadata from the runtime and deploy time code.
`metadata.useLiteralContent`	boolean	False	Use only literal content and not URLs
`metadata.bytecodeHash`	string	"ipfs"	Use the given hash method for the metadata hash that is appended to the bytecode. The metadata hash can be removed from the bytecode via option "none". The other options are "ipfs" and "bzzr1".

Libraries

The libraries object provides addresses for linked library contracts. If not all libraries are given here, it can result in unlinked objects whose output data is different.

The top level key is the name of the source file where the library is used. If remappings are used, this source file should match the global path after remappings were applied. If this key is an empty string, that refers to a global level. Each value is an object mapping library names to their deployed addresses. Example:

"myFile.sol": {
  "MyLib": "0x123..."
}

Output Selection

The outputSelection object can be used to select desired outputs based on file and contract names. If this is omitted, then the compiler loads and does type checking, but will not generate any outputs apart from errors. The first level key is the file name and the second level key is the contract name. An empty contract name is used for outputs that are not tied to a contract but to the whole source file like the AST. A star as contract name refers to all contracts in the file. Similarly, a star as a file name matches all files. To select all outputs the compiler can possibly generate, with the exclusion of Yul intermediate representation outputs, use "outputSelection: { "*": { "*": [ "*" ], "": [ "*" ] } }" but note that this might slow down the compilation process needlessly. The available output types are as follows:

File level (needs empty string as contract name):
- ast - AST of all source files
Contract level (needs the contract name or "*"):
- abi - ABI
- devdoc - Developer documentation (natspec)
- userdoc - User documentation (natspec)
- metadata - Metadata
- ir - Yul intermediate representation of the code before optimization
- irAst - AST of Yul intermediate representation of the code before optimization (experimental)
- irOptimized - Intermediate representation after optimization
- irOptimizedAst - AST of intermediate representation after optimization (experimental)
- storageLayout - Slots, offsets and types of the contract's state variables in storage
- transientStorageLayout - Slots, offsets and types of the contract's state variables in transient storage
- evm.assembly - New assembly format
- evm.legacyAssembly - Old-style assembly format in JSON
- evm.bytecode.ethdebug - Debug information in ethdebug format (ethdebug/format/program schema). Can only be requested when compiling via IR. (experimental)
- evm.deployedBytecode.ethdebug - Like evm.bytecode.ethdebug, but for the runtime part of the contract (experimental)
- evm.bytecode.functionDebugData - Debugging information at function level
- evm.bytecode.object - Bytecode object
- evm.bytecode.opcodes - Opcodes list
- evm.bytecode.sourceMap - Source mapping (useful for debugging)
- evm.bytecode.linkReferences - Link references (if unlinked object)
- evm.bytecode.generatedSources - Sources generated by the compiler
- evm.deployedBytecode* - Deployed bytecode (has all the options that evm.bytecode has)
- evm.deployedBytecode.immutableReferences - Map from AST ids to bytecode ranges that reference immutables
- evm.methodIdentifiers - The list of function hashes
- evm.gasEstimates - Function gas estimates
- yulCFGJson - Control Flow Graph (CFG) of the Single Static Assignment (SSA) form of the contract (experimental)

Note that Using evm, evm.bytecode, etc. will select every target part of that output. Additionally, * can be used as a wildcard to request everything.

Model Checker Settings

The modelChecker object configures the built-in SMTChecker for formal verification of contracts. The model checker settings are experimental and subject to change.

Field	Type	Description
`contracts`	object	Map of source files to arrays of contract names that should be analyzed as deployed contracts.
`divModNoSlacks`	boolean	Choose how division and modulo operations should be encoded. When using `false` they are replaced by multiplication with slack variables. This is the default. Using `true` here is recommended if you are using the CHC engine and not using Spacer as the Horn solver (using Eldarica, for example). See the Formal Verification section <formal_verification> for a more detailed explanation.
`engine`	string	Choose which model checker engine to use: all (default), bmc, chc, none.
`modelChecker.extCalls`	string	Choose whether external calls should be considered trusted in case the code of the called function is available at compile-time. For details see the SMTChecker section <formal_verification>.
`modelChecker.invariants`	string[]	Choose which types of invariants should be reported to the user: contract, reentrancy.
`modelChecker.showProvedSafe`	boolean	Choose whether to output all proved targets. The default is `false`.
`modelChecker.showUnproved`	boolean	Choose whether to output all unproved targets. The default is `false`.
`modelChecker.showUnsupported`	boolean	Choose whether to output all unsupported language features. The default is `false`.
`modelChecker.solvers`	string[]	Choose which solvers should be used, if available. Options: `"cvc5"`, `"smtlib2"`, `"z3"`. See the Formal Verification section <formal_verification> for the solvers description.
`modelChecker.targets`	string[]	Choose which targets should be checked. Options: constantCondition, underflow, overflow, divByZero, balance, assert, popEmptyArray, outOfBounds. If the option is not given all targets are checked by default, except underflow/overflow for Solidity >=0.8.7. See the Formal Verification section <formal_verification> for the targets description.
`modelChecker.timeout`	integer	Timeout for each SMT query in milliseconds. If this option is not given, the SMTChecker will use a deterministic resource limit by default. A given timeout of 0 means no resource/time restrictions for any query.

Example: TODO: cleanup. complete settings? Minimal and realistic?

{
  // Required: Source code language. Currently supported are "Solidity", "Yul", "SolidityAST" (experimental), "EVMAssembly" (experimental).
  "language": "Solidity",
  // Required
  "sources":
  {
    // The keys here are the "global" names of the source files,
    // imports can use other files via remappings (see below).
    "myFile.sol":
    {
      // Optional: keccak256 hash of the source file
      // It is used to verify the retrieved content if imported via URLs.
      "keccak256": "0x123...",
      // Required (unless "content" is used, see below): URL(s) to the source file.
      // URL(s) should be imported in this order and the result checked against the
      // keccak256 hash (if available). If the hash doesn't match or none of the
      // URL(s) result in success, an error should be raised.
      // Using the commandline interface only filesystem paths are supported.
      // With the JavaScript interface the URL will be passed to the user-supplied
      // read callback, so any URL supported by the callback can be used.
      "urls":
      [
        "bzzr://56ab...",
        "ipfs://Qma...",
        "/tmp/path/to/file.sol"
        // If files are used, their directories should be added to the command-line via
        // `--allow-paths <path>`.
      ]
    },
    "settable":
    {
      // Optional: keccak256 hash of the source file
      "keccak256": "0x234...",
      // Required (unless "urls" is used): literal contents of the source file
      "content": "contract settable is owned { uint256 private x = 0; function set(uint256 _x) public { if (msg.sender == owner) x = _x; } }"
    },
    "myFile.sol_json.ast":
    {
      // If language is set to "SolidityAST", an AST needs to be supplied under the "ast" key
      // and there can be only one source file present.
      // The format is the same as used by the `ast` output.
      // Note that importing ASTs is experimental and in particular that:
      // - importing invalid ASTs can produce undefined results and
      // - no proper error reporting is available on invalid ASTs.
      // Furthermore, note that the AST import only consumes the fields of the AST as
      // produced by the compiler in "stopAfter": "parsing" mode and then re-performs
      // analysis, so any analysis-based annotations of the AST are ignored upon import.
      "ast": { ... }
    },
    "myFile_evm.json":
    {
      // If language is set to "EVMAssembly", an EVM Assembly JSON object needs to be supplied
      // under the "assemblyJson" key and there can be only one source file present.
      // The format is the same as used by the `evm.legacyAssembly` output or `--asm-json`
      // output on the command line.
      // Note that importing EVM assembly is experimental.
      "assemblyJson":
      {
        ".code": [ ... ],
        ".data": { ... }, // optional
        "sourceList": [ ... ] // optional (if no `source` node was defined in any `.code` object)
      }
    }
  },
  // Optional
  "settings":
  {
    // Optional: Stop compilation after the given stage. Currently only "parsing" is valid here
    "stopAfter": "parsing",
    // Optional: List of remappings
    "remappings": [ ":g=/dir" ],
    // Optional: Experimental mode toggle (Default: false)
    // Makes it possible to use experimental features (but does not enable any such feature by itself).
    // The use of this mode is recorded in contract metadata.
    "experimental": true,
    // Optional: Optimizer settings
    "optimizer": {
      // Turn on the optimizer. Optional. Default: false.
      // NOTE: The state of the optimizer is fully determined by the 'details' dict and this setting
      // only affects its defaults - when enabled, all components default to being enabled.
      // The opposite is not true - there are several components that always default to being
      // enabled an can only be explicitly disabled via 'details'.
      // WARNING: Before version 0.8.6 omitting this setting was not equivalent to setting
      // it to false and would result in all components being disabled instead.
      // WARNING: Enabling optimizations for EVMAssembly input is allowed but not necessary under normal
      // circumstances. It forces the opcode-based optimizer to run again and can produce bytecode that
      // is not reproducible from metadata.
      "enabled": true,
      // Optimize for how many times you intend to run the code. Optional. Default: 200.
      // Lower values will optimize more for initial deployment cost, higher
      // values will optimize more for high-frequency usage.
      "runs": 200,
      // State of all optimizer components. Optional.
      // Default values are determined by whether the optimizer is enabled or not.
      // Note that the 'enabled' setting only affects the defaults here and has no effect when
      // all values are provided explicitly.
      "details": {
        // Peephole optimizer (opcode-based). Optional. Default: true.
        // Default for EVMAssembly input: false when optimization is not enabled.
        // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.
        "peephole": true,
        // Inliner (opcode-based). Optional. Default: true when optimization is enabled.
        "inliner": false,
        // Unused JUMPDEST remover (opcode-based). Optional. Default: true.
        // Default for EVMAssembly input: false when optimization is not enabled.
        // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.
        "jumpdestRemover": true,
        // Literal reordering (codegen-based). Optional. Default: true when optimization is enabled.
        // Moves literals to the right of commutative binary operators during code generation, helping exploit associativity.
        "orderLiterals": false,
        // Block deduplicator (opcode-based). Optional. Default: true when optimization is enabled.
        // Unifies assembly code blocks that share content.
        "deduplicate": false,
        // Common subexpression elimination (opcode-based). Optional. Default: true when optimization is enabled.
        // This is the most complicated step but can also provide the largest gain.
        "cse": false,
        // Constant optimizer (opcode-based). Optional. Default: true when optimization is enabled.
        // Tries to find better representations of literal numbers and strings, that satisfy the
        // size/cost trade-off determined by the 'runs' setting.
        "constantOptimizer": false,
        // Unchecked loop increment (codegen-based). Optional. Default: true.
        // Use unchecked arithmetic when incrementing the counter of 'for' loops under certain circumstances.
        // NOTE: Always runs (even with optimization disabled) unless explicitly turned off here.
        "simpleCounterForLoopUncheckedIncrement": true,
        // Yul optimizer. Optional. Default: true when optimization is enabled.
        // Used to optimize the IR produced by the Yul IR-based pipeline as well as inline assembly
        // and utility Yul code generated by the compiler.
        // NOTE: Before Solidity 0.6.0 the default was false.
        "yul": false,
        // Tuning options for the Yul optimizer. Optional.
        "yulDetails": {
          // Improve allocation of stack slots for variables, can free up stack slots early.
          // Optional. Default: true if Yul optimizer is enabled.
          "stackAllocation": true,
          // Optimization step sequence.
          // The general form of the value is "<main sequence>:<cleanup sequence>".
          // The setting is optional and when omitted, default values are used for both sequences.
          // If the value does not contain the ':' delimiter, it is interpreted as the main
          // sequence and the default is used for the cleanup sequence.
          // To make one of the sequences empty, the delimiter must be present at the first or last position.
          // In particular if the whole value consists only of the delimiter, both sequences are empty.
          // Note that there are several hard-coded steps that always run, even when both sequences are empty.
          // For more information see "The Optimizer > Selecting Optimizations".
          "optimizerSteps": "dfDvulfnTUtnIf..."
        }
      }
    },
    // Version of the EVM to compile for (optional).
    // Affects type checking and code generation. Can be homestead,
    // tangerineWhistle, spuriousDragon, byzantium, constantinople,
    // petersburg, istanbul, berlin, london, paris, shanghai, cancun,
    // prague, osaka (default), or @future (experimental).
    "evmVersion": "osaka",
    // EVM Object Format version to compile for (optional, experimental).
    // Currently the only valid value is 1. If not specified, legacy non-EOF bytecode will be generated.
    // Requires `evmVersion` >= osaka.
    "eofVersion": null,
    // Optional: Change compilation pipeline to go through the Yul intermediate representation.
    // This is false by default.
    "viaIR": true,
    // Optional: Turn on SSA CFG-based code generation via the IR (experimental).
    // Implies viaIR: true. This is false by default.
    "viaSSACFG": false,
    // Optional: Debugging settings
    "debug": {
      // How to treat revert (and require) reason strings. Settings are
      // "default", "strip", "debug" and "verboseDebug".
      // "default" does not inject compiler-generated revert strings and keeps user-supplied ones.
      // "strip" removes all revert strings (if possible, i.e. if literals are used) keeping side-effects.
      // NOTE: "strip" does not remove custom errors.
      // WARNING: Before Solidity 0.8.35, "strip" in the IR pipeline used to remove custom errors.
      // "debug" injects strings for compiler-generated internal reverts, implemented for ABI encoders V1 and V2 for now.
      // "verboseDebug" even appends further information to user-supplied revert strings (not yet implemented)
      "revertStrings": "default",
      // Optional: How much extra debug information to include in comments in the produced EVM
      // assembly and Yul code. Available components are:
      // - `location`: Annotations of the form `@src <index>:<start>:<end>` indicating the
      //    location of the corresponding element in the original Solidity file, where:
      //     - `<index>` is the file index matching the `@use-src` annotation,
      //     - `<start>` is the index of the first byte at that location,
      //     - `<end>` is the index of the first byte after that location.
      // - `snippet`: A single-line code snippet from the location indicated by `@src`.
      //     The snippet is quoted and follows the corresponding `@src` annotation.
      // - `ast-id`: Annotations of the form `@ast-id <id>` over elements that can be mapped back to a definition in the original Solidity file.
      //   `<id>` is a node ID in the Solidity AST ('ast' output).
      // - `ethdebug`: Ethdebug annotations (experimental).
      // - `*`: Wildcard value that can be used to request all non-experimental components.
      "debugInfo": ["location", "snippet", "ast-id", "ethdebug"]
    },
    // Metadata settings (optional)
    "metadata": {
      // The CBOR metadata is appended at the end of the bytecode by default.
      // Setting this to false omits the metadata from the runtime and deploy time code.
      "appendCBOR": true,
      // Use only literal content and not URLs (false by default)
      "useLiteralContent": true,
      // Use the given hash method for the metadata hash that is appended to the bytecode.
      // The metadata hash can be removed from the bytecode via option "none".
      // The other options are "ipfs" and "bzzr1".
      // If the option is omitted, "ipfs" is used by default.
      "bytecodeHash": "ipfs"
    },
    // Addresses of the libraries. If not all libraries are given here,
    // it can result in unlinked objects whose output data is different.
    "libraries": {
      // The top level key is the name of the source file where the library is used.
      // If remappings are used, this source file should match the global path
      // after remappings were applied.
      // If this key is an empty string, that refers to a global level.
      "myFile.sol": {
        "MyLib": "0x123123..."
      }
    },
    // The following can be used to select desired outputs based
    // on file and contract names.
    // If this field is omitted, then the compiler loads and does type checking,
    // but will not generate any outputs apart from errors.
    // The first level key is the file name and the second level key is the contract name.
    // An empty contract name is used for outputs that are not tied to a contract
    // but to the whole source file like the AST.
    // A star as contract name refers to all contracts in the file.
    // Similarly, a star as a file name matches all files.
    // To select all outputs the compiler can possibly generate, with the exclusion of
    // Yul intermediate representation outputs, use
    // "outputSelection: { "*": { "*": [ "*" ], "": [ "*" ] } }"
    // but note that this might slow down the compilation process needlessly.
    //
    // The available output types are as follows:
    //
    // File level (needs empty string as contract name):
    //   ast - AST of all source files
    //
    // Contract level (needs the contract name or "*"):
    //   abi - ABI
    //   devdoc - Developer documentation (natspec)
    //   userdoc - User documentation (natspec)
    //   metadata - Metadata
    //   ir - Yul intermediate representation of the code before optimization
    //   irAst - AST of Yul intermediate representation of the code before optimization (experimental)
    //   irOptimized - Intermediate representation after optimization
    //   irOptimizedAst - AST of intermediate representation after optimization (experimental)
    //   storageLayout - Slots, offsets and types of the contract's state variables in storage
    //   transientStorageLayout - Slots, offsets and types of the contract's state variables in transient storage
    //   evm.assembly - New assembly format
    //   evm.legacyAssembly - Old-style assembly format in JSON
    //   evm.bytecode.ethdebug - Debug information in ethdebug format (ethdebug/format/program schema). Can only be requested when compiling via IR. (experimental)
    //   evm.deployedBytecode.ethdebug - Like evm.bytecode.ethdebug, but for the runtime part of the contract (experimental)
    //   evm.bytecode.functionDebugData - Debugging information at function level
    //   evm.bytecode.object - Bytecode object
    //   evm.bytecode.opcodes - Opcodes list
    //   evm.bytecode.sourceMap - Source mapping (useful for debugging)
    //   evm.bytecode.linkReferences - Link references (if unlinked object)
    //   evm.bytecode.generatedSources - Sources generated by the compiler
    //   evm.deployedBytecode* - Deployed bytecode (has all the options that evm.bytecode has)
    //   evm.deployedBytecode.immutableReferences - Map from AST ids to bytecode ranges that reference immutables
    //   evm.methodIdentifiers - The list of function hashes
    //   evm.gasEstimates - Function gas estimates
    //   yulCFGJson - Control Flow Graph (CFG) of the Single Static Assignment (SSA) form of the contract (experimental)
    //
    // Note that using `evm`, `evm.bytecode`, etc. will select every
    // target part of that output. Additionally, `*` can be used as a wildcard to request everything.
    //
    "outputSelection": {
      "*": {
        "*": [
          "metadata", "evm.bytecode" // Enable the metadata and bytecode outputs of every single contract.
          , "evm.bytecode.sourceMap" // Enable the source map output of every single contract.
        ],
        "": [
          "ast" // Enable the AST output of every single file.
        ]
      },
      // Enable the abi and opcodes output of MyContract defined in file def.
      "def": {
        "MyContract": [ "abi", "evm.bytecode.opcodes" ]
      }
    },
    // The modelChecker object is experimental and subject to changes.
    "modelChecker":
    {
      // Chose which contracts should be analyzed as the deployed one.
      "contracts":
      {
        "source1.sol": ["contract1"],
        "source2.sol": ["contract2", "contract3"]
      },
      // Choose how division and modulo operations should be encoded.
      // When using `false` they are replaced by multiplication with slack
      // variables. This is the default.
      // Using `true` here is recommended if you are using the CHC engine
      // and not using Spacer as the Horn solver (using Eldarica, for example).
      // See the Formal Verification section for a more detailed explanation of this option.
      "divModNoSlacks": false,
      // Choose which model checker engine to use: all (default), bmc, chc, none.
      "engine": "chc",
      // Choose whether external calls should be considered trusted in case the
      // code of the called function is available at compile-time.
      // For details see the SMTChecker section.
      "extCalls": "trusted",
      // Choose which types of invariants should be reported to the user: contract, reentrancy.
      "invariants": ["contract", "reentrancy"],
      // Choose whether to output all proved targets. The default is `false`.
      "showProvedSafe": true,
      // Choose whether to output all unproved targets. The default is `false`.
      "showUnproved": true,
      // Choose whether to output all unsupported language features. The default is `false`.
      "showUnsupported": true,
      // Choose which solvers should be used, if available.
      // See the Formal Verification section for the solvers description.
      "solvers": ["cvc5", "smtlib2", "z3"],
      // Choose which targets should be checked: constantCondition,
      // underflow, overflow, divByZero, balance, assert, popEmptyArray, outOfBounds.
      // If the option is not given all targets are checked by default,
      // except underflow/overflow for Solidity >=0.8.7.
      // See the Formal Verification section for the targets description.
      "targets": ["underflow", "overflow", "assert"],
      // Timeout for each SMT query in milliseconds.
      // If this option is not given, the SMTChecker will use a deterministic
      // resource limit by default.
      // A given timeout of 0 means no resource/time restrictions for any query.
      "timeout": 20000
    }
  }
}

Output Description

The Solidity Standard JSON Output is the structured result returned by the Solidity compiler after processing a Standard JSON Input file. The output object is shaped by the outputSelection field in the input JSON file, only the artifacts explicitly requested are included in the response. Errors and warnings are always returned regardless of output selection settings.

The root JSON output object contains up to four top-level keys.

Field	Type	Required	Description
`errors`	array	No	Not present if no errors, warnings, infos were encountered.
`sources`	object	Yes	This contains the file-level outputs. It can be limited/filtered by the outputSelection settings.
`contracts`	object	Yes	This contains the contract-level outputs. It can be limited/filtered by the outputSelection settings.
`ethdebug`	object	No	Global Ethdebug output (experimental).

Errors

The errors array contains diagnostic messages produced during compilation. Each element is an object describing an error, warning, or info message.

Field	Type	Required	Description
`type`	string	Yes	Error type, such as "TypeError", "InternalCompilerError", "Exception", etc. See below for complete list of types.
`component`	string	Yes	Component where the error originated, such as "general" etc.
`severity`	string	Yes	Possible values are "error", "warning" or "info", but please note that this may be extended in the future.
`errorCode`	string	No	Unique code for the cause of the error.
`message`	string	Yes	The error message.
`formattedMessage`	string	No	The message formatted with source location.
`sourceLocation`	object	No	Location within the source file. Contains three fields, "file", "start", "end".
`secondarySourceLocations`	array	No	Further locations (e.g. places of conflicting declarations). Contains the same fields of "sourceLocation" and also "message".

Error Types

JSONError: JSON input doesn't conform to the required format, e.g. input is not a JSON object, the language is not supported, etc.
IOError: IO and import processing errors, such as unresolvable URL or hash mismatch in supplied sources.
ParserError: Source code doesn't conform to the language rules.
DocstringParsingError: The NatSpec tags in the comment block cannot be parsed.
SyntaxError: Syntactical error, such as continue is used outside of a for loop.
DeclarationError: Invalid, unresolvable or clashing identifier names. e.g. Identifier not found
TypeError: Error within the type system, such as invalid type conversions, invalid assignments, etc.
UnimplementedFeatureError: Feature is not supported by the compiler, but is expected to be supported in future versions.
InternalCompilerError: Internal bug triggered in the compiler - this should be reported as an issue.
Exception: Unknown failure during compilation - this should be reported as an issue.
CompilerError: Invalid use of the compiler stack - this should be reported as an issue.
FatalError: Fatal error not processed correctly - this should be reported as an issue.
YulException: Error during Yul code generation - this should be reported as an issue.
Warning: A warning, which didn't stop the compilation, but should be addressed if possible.
Info: Information that the compiler thinks the user might find useful, but is not dangerous and does not necessarily need to be addressed.

Sources

The sources object in the output contains file-level compilation artifacts. Each entry corresponds to a source file provided in the input.

id: Identifier of the source (used in source maps).
ast: The AST object.

Contracts

The contracts object is organized as a two-level map: the first level key is the source file name, and the second level key is the contract name. If the language has no concept of contract names (e.g., Yul), the contract name is an empty string.

Field	Type	Description
`abi`	array	The Ethereum Contract ABI. If empty, it is represented as an empty array. See :ref:`ABI section <ABI>`.
`metadata`	string	See the :ref:`Metadata Output documentation<metadata>` (serialised JSON string).
`userdoc`	object	User documentation (see :ref:`Natspec Format<natspec>`).
`devdoc`	object	Developer documentation (see :ref:`Natspec Format<natspec>`).
`ir`	string	Intermediate representation before optimization.
`irAst`	object	AST of intermediate representation before optimization.
`irOptimized`	string	Intermediate representation after optimization.
`irOptimizedAst`	object	AST of intermediate representation after optimization.
`storageLayout`	object	Describes the :ref:`storage layout <storage-layout>`.
`transientStorageLayout`	object	Describes the :ref:`transient storage layout <storage-layout>`.
`evm`	object	EVM-related outputs. Described below.

evm

The evm object is the largest output section, containing all bytecode, assembly, debugging data, method identifiers, and gas estimates for a contract.

Field	Type	Description
`assembly`	string	New format EVM assembly representation of the compiled contract as a human-readable string.
`legacyAssembly`	object	Old style assembly output as a structured JSON object. Contains code arrays, data sections, and source references. Corresponds to the `--asm-json` CLI flag.
`bytecode`	object	Contains immutable references and ethdebug (experimental).
`deployedBytecode`	object	Contains immutable references and ethdebug (experimental).
`methodIdentifiers`	object	The list of function hashes. Maps thje name of the method to its hash.
`gasEstimates`	object	Function gas estimates.
`yulCFGJson`	object	Yul CFG representation of the SSA form (experimental).

evm.bytecode

The evm.bytecode object contains the deployment (creation) bytecode and all associated debugging and linking metadata. The deployment bytecode is the code that runs during contract creation and returns the runtime bytecode.

Field	Type	Description
`object`	string	The compiled bytecode as a hex string.
`opcodes`	string	Opcode list.
`sourceMap`	string	The source mapping as a string. See the source mapping definition.
`generatedSources`	array	Array of sources generated by the compiler. Currently only contains a single Yul file.
`linkReferences`	object	If given, this is an unlinked object. References for unlinked library calls.
`functionDebugData`	object	Debugging data at the level of functions.
`ethdebug`	object	Debug information in the ethdebug format (experimental).

The evm.deployedBytecode object has the same structure as evm.bytecode. Additionally, it includes the immutableReferences suboject which maps AST IDs of immutables to their bytecode offset and size. For example, two references to the immutable with AST ID 3, both 32 bytes, the first one at bytecode offset 42, and the other at bytecode offset 80, is specified as:

"immutableReferences": {
  "3": [{ "start": 42, "length": 32 }, { "start": 80, "length": 32 }]
}

Gas Estimates

The evm.gasEstimates object provides estimated gas costs for contract creation and function execution.

creation: Gas estimates for contract deployment. Contains three string fields.
- codeDepositCost: Gas to store the runtime bytecode on-chain.
- executionCost: Gas to execute the constructor
- totalCost: Sum of both previous costs.
external: Map of external/public function signatures to their estimated execution gas cost as a string.
internal: Map of internal function names to their estimated execution gas cost as a string.

Note

Values may be "infinite" if the compiler cannot determine a bound.

Yul CFG

Experimental. Yul CFG representation of the SSA form.

Ethdebug

Experimental.

Example: TODO: cleanup.

{
  // Optional: not present if no errors/warnings/infos were encountered
  "errors": [
    {
      // Optional: Location within the source file.
      "sourceLocation": {
        "file": "sourceFile.sol",
        "start": 0,
        "end": 100
      },
      // Optional: Further locations (e.g. places of conflicting declarations)
      "secondarySourceLocations": [
        {
          "file": "sourceFile.sol",
          "start": 64,
          "end": 92,
          "message": "Other declaration is here:"
        }
      ],
      // Mandatory: Error type, such as "TypeError", "InternalCompilerError", "Exception", etc.
      // See below for complete list of types.
      "type": "TypeError",
      // Mandatory: Component where the error originated, such as "general" etc.
      "component": "general",
      // Mandatory ("error", "warning" or "info", but please note that this may be extended in the future)
      "severity": "error",
      // Optional: unique code for the cause of the error
      "errorCode": "3141",
      // Mandatory
      "message": "Invalid keyword",
      // Optional: the message formatted with source location
      "formattedMessage": "sourceFile.sol:100: Invalid keyword"
    }
  ],
  // This contains the file-level outputs.
  // It can be limited/filtered by the outputSelection settings.
  "sources": {
    "sourceFile.sol": {
      // Identifier of the source (used in source maps)
      "id": 1,
      // The AST object
      "ast": {}
    }
  },
  // This contains the contract-level outputs.
  // It can be limited/filtered by the outputSelection settings.
  "contracts": {
    "sourceFile.sol": {
      // If the language used has no contract names, this field should equal to an empty string.
      "ContractName": {
        // The Ethereum Contract ABI. If empty, it is represented as an empty array.
        // See https://docs.soliditylang.org/en/develop/abi-spec.html
        "abi": [],
        // See the Metadata Output documentation (serialised JSON string)
        "metadata": "{/* ... */}",
        // User documentation (natspec)
        "userdoc": {},
        // Developer documentation (natspec)
        "devdoc": {},
        // Intermediate representation before optimization (string)
        "ir": "",
        // AST of intermediate representation before optimization
        "irAst":  {/* ... */},
        // Intermediate representation after optimization (string)
        "irOptimized": "",
        // AST of intermediate representation after optimization
        "irOptimizedAst": {/* ... */},
        // See the Storage Layout documentation.
        "storageLayout": {"storage": [/* ... */], "types": {/* ... */} },
        // See the Storage Layout documentation.
        "transientStorageLayout": {"storage": [/* ... */], "types": {/* ... */} },
        // EVM-related outputs
        "evm": {
          // Assembly (string)
          "assembly": "",
          // Old-style assembly (object)
          "legacyAssembly": {},
          // Bytecode and related details.
          "bytecode": {
            // Ethdebug output (experimental)
            "ethdebug": {/* ... */},
            // Debugging data at the level of functions.
            "functionDebugData": {
              // Now follows a set of functions including compiler-internal and
              // user-defined function. The set does not have to be complete.
              "@mint_13": { // Internal name of the function
                "entryPoint": 128, // Byte offset into the bytecode where the function starts (optional)
                "id": 13, // AST ID of the function definition or null for compiler-internal functions (optional)
                "parameterSlots": 2, // Number of EVM stack slots for the function parameters (optional)
                "returnSlots": 1 // Number of EVM stack slots for the return values (optional)
              }
            },
            // The bytecode as a hex string.
            "object": "00fe",
            // Opcodes list (string)
            "opcodes": "",
            // The source mapping as a string. See the source mapping definition.
            "sourceMap": "",
            // Array of sources generated by the compiler. Currently only
            // contains a single Yul file.
            "generatedSources": [{
              // Yul AST
              "ast": {/* ... */},
              // Source file in its text form (may contain comments)
              "contents":"{ function abi_decode(start, end) -> data { data := calldataload(start) } }",
              // Source file ID, used for source references, same "namespace" as the Solidity source files
              "id": 2,
              "language": "Yul",
              "name": "#utility.yul"
            }],
            // If given, this is an unlinked object.
            "linkReferences": {
              "libraryFile.sol": {
                // Byte offsets into the bytecode.
                // Linking replaces the 20 bytes located there.
                "Library1": [
                  { "start": 0, "length": 20 },
                  { "start": 200, "length": 20 }
                ]
              }
            }
          },
          "deployedBytecode": {
            // Ethdebug output (experimental)
            "ethdebug": {/* ... */},
            /* ..., */ // The same layout as above.
            "immutableReferences": {
              // There are two references to the immutable with AST ID 3, both 32 bytes long. One is
              // at bytecode offset 42, the other at bytecode offset 80.
              "3": [{ "start": 42, "length": 32 }, { "start": 80, "length": 32 }]
            }
          },
          // The list of function hashes
          "methodIdentifiers": {
            "delegate(address)": "5c19a95c"
          },
          // Function gas estimates
          "gasEstimates": {
            "creation": {
              "codeDepositCost": "420000",
              "executionCost": "infinite",
              "totalCost": "infinite"
            },
            "external": {
              "delegate(address)": "25000"
            },
            "internal": {
              "heavyLifting()": "infinite"
            }
          },
          // Yul CFG representation of the SSA form (experimental)
          "yulCFGJson": {/* ... */}
        }
      }
    }
  },
  // Global Ethdebug output (experimental)
  "ethdebug": {/* ... */ }
}

.. index:: ! Experimental mode, ! --experimental

Experimental Mode

Some language and compiler features included in stable releases are not themselves considered stable. They are sparsely documented, if at all, often not adequately tested, and thus not yet intended for production use. In many cases it is possible to develop a big feature incrementally, with each iteration being already stable. Sometimes, however, it is preferable to start with a prototype and stabilize it over multiple releases, while receiving feedback from users. To prevent accidental use, such features can be only accessed by enabling the experimental mode.

There are no backwards compatibility guarantees for experimental features. They are subject to change in breaking ways in non-breaking releases of the compiler. Only major changes affecting them are recorded in the changelog.

To enable the experimental mode, use the --experimental flag on the command line, or the analogous settings.experimental boolean setting in the Standard JSON input.

Note that the use of this mode is recorded in the metadata:

experimental flag in CBOR metadata is set to true,
settings.experimental in JSON metadata is set to true,

Note

Prior to version 0.8.34, most of the experimental features were usable without any extra safeguards. Some were gated behind pragma experimental, but this was not done consistently. The information about them was also only recorded in CBOR metadata and even then not always. The main goal of the experimental mode is to systematize this and make users fully aware when relying on features which are unfinished or not production-ready.

The table below details all currently available experimental features.

Feature	ID	Affects bytecode	Flag/pragma
AST import	`ast-import`	yes	`--import-ast`
LSP	`lsp`	no	`--lsp`
EVM Assembly import	`evmasm-import`	yes	`--import-asm-json`
Generic Solidity	`generic-solidity`	yes	`pragma experimental solidity`
IR AST	`ir-ast`	no	`--ir-ast-json`, `--ir-optimized-ast-json`
EOF	`eof`	yes	`--experimental-eof-version`
Non-mainnet EVMs	`evm`	yes	`--evm-version <version name>`
Ethdebug	`ethdebug`	no	`--ethdebug`, `--ethdebug-runtime`, `--debug-info ethdebug`
SSA CFG	`ssa-cfg`	no	`--yul-cfg-json`
SSA CFG	`ssa-cfg`	yes	`--via-ssa-cfg`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using the Compiler

Using the Commandline Compiler

Basic Usage

Optimizer Options

Base Path and Import Remapping

Library Linking

Setting the EVM Version to Target

Target Options

Compiler Input and Output JSON Description

Input Description

Sources

keccak256

urls

ast

assemblyJson

Settings

General Settings

Optimizer Settings

Debug Settings

Metadata Settings

Libraries

Output Selection

Model Checker Settings

Output Description

Errors

Error Types

Sources

Contracts

evm

evm.bytecode

Gas Estimates

Yul CFG

Ethdebug

Experimental Mode

FilesExpand file tree

using-the-compiler.rst

Latest commit

History

using-the-compiler.rst

File metadata and controls

Using the Compiler

Using the Commandline Compiler

Basic Usage

Optimizer Options

Base Path and Import Remapping

Library Linking

Setting the EVM Version to Target

Target Options

Compiler Input and Output JSON Description

Input Description

Sources

keccak256

urls

ast

assemblyJson

Settings

General Settings

Optimizer Settings

Debug Settings

Metadata Settings

Libraries

Output Selection

Model Checker Settings

Output Description

Errors

Error Types

Sources

Contracts

evm

evm.bytecode

Gas Estimates

Yul CFG

Ethdebug

Experimental Mode