forge selectors collision

Check for selector collisions between contracts

$ forge selectors collision --help
Usage: forge selectors collision [OPTIONS] <FIRST_CONTRACT> <SECOND_CONTRACT> Arguments: <FIRST_CONTRACT> The first of the two contracts for which to look selector collisions for, in the form `(<path>:)?<contractname>` <SECOND_CONTRACT> The second of the two contracts for which to look selector collisions for, in the form `(<path>:)?<contractname>` Options: -h, --help Print help (see a summary with '-h') -j, --threads <THREADS> Number of threads to use. Specifying 0 defaults to the number of logical cores [aliases: jobs] Cache options: --force Clear the cache and artifacts folder and recompile Build options: --no-cache Disable the cache --eof Whether to compile contracts to EOF bytecode --skip <SKIP>... Skip building files whose names contain the given filter. `test` and `script` are aliases for `.t.sol` and `.s.sol`. Linker options: --libraries <LIBRARIES> Set pre-linked libraries [env: DAPP_LIBRARIES=] Compiler options: --ignored-error-codes <ERROR_CODES> Ignore solc warnings by error code --deny-warnings Warnings will trigger a compiler error --no-auto-detect Do not auto-detect the `solc` version --use <SOLC_VERSION> Specify the solc version, or a path to a local solc, to build with. Valid values are in the format `x.y.z`, `solc:x.y.z` or `path/to/solc`. --offline Do not access the network. Missing solc versions will not be installed. --via-ir Use the Yul intermediate representation compilation pipeline --use-literal-content Changes compilation to only use literal content and not URLs --no-metadata Do not append any metadata to the bytecode. This is equivalent to setting `bytecode_hash` to `none` and `cbor_metadata` to `false`. --ast Includes the AST as JSON in the compiler output --evm-version <VERSION> The target EVM version --optimize [<OPTIMIZE>] Activate the Solidity optimizer [possible values: true, false] --optimizer-runs <RUNS> The number of runs specifies roughly how often each opcode of the deployed code will be executed across the life-time of the contract. This means it is a trade-off parameter between code size (deploy cost) and code execution cost (cost after deployment). An `optimizer_runs` parameter of `1` will produce short but expensive code. In contrast, a larger `optimizer_runs` parameter will produce longer but more gas efficient code --extra-output <SELECTOR>... Extra output to include in the contract's artifact. Example keys: evm.assembly, ewasm, ir, irOptimized, metadata For a full description, see <https://docs.soliditylang.org/en/v0.8.13/using-the-compiler.html#input-description> --extra-output-files <SELECTOR>... Extra output to write to separate files. Valid values: metadata, ir, irOptimized, ewasm, evm.assembly Project options: -o, --out <PATH> The path to the contract artifacts folder --revert-strings <REVERT> Revert string configuration. Possible values are "default", "strip" (remove), "debug" (Solidity-generated revert strings) and "verboseDebug" --build-info Generate build info files --build-info-path <PATH> Output path to directory that build info files will be written to --root <PATH> The project's root path. By default root of the Git repository, if in one, or the current working directory. -C, --contracts <PATH> The contracts source directory -R, --remappings <REMAPPINGS> The project's remappings --remappings-env <ENV> The project's remappings from the environment --cache-path <PATH> The path to the compiler cache --lib-paths <PATH> The path to the library folder --hardhat Use the Hardhat-style project layout. This is the same as using: `--contracts contracts --lib-paths node_modules`. [aliases: hh] --config-path <FILE> Path to the config file Display options: --color <COLOR> The color of the log messages Possible values: - auto: Intelligently guess whether to use color output (default) - always: Force color output - never: Force disable color output --json Format log messages as JSON -q, --quiet Do not print log messages -v, --verbosity... Verbosity level of the log messages. Pass multiple times to increase the verbosity (e.g. -v, -vv, -vvv). Depending on the context the verbosity levels have different meanings. For example, the verbosity levels of the EVM are: - 2 (-vv): Print logs for all tests. - 3 (-vvv): Print execution traces for failing tests. - 4 (-vvvv): Print execution traces for all tests, and setup traces for failing tests. - 5 (-vvvvv): Print execution and setup traces for all tests, including storage changes.