feat(script): revert if address(this) used

[gap-editor]

Motivation

Closes #10289

Users can accidentally use address(this) within forge script contracts, often intending to refer to the script contract itself for operations like transferring ownership or sending tokens during deployment. However, the address(this) in a script context refers to a temporary, locally deployed contract instance used for the simulation. This address does not exist on the target network and relying on it leads to deployment errors or incorrect state on-chain.

This PR introduces a warning mechanism to alert users when address(this) is used during a forge script execution, helping prevent these common mistakes.

Solution

1. Introduced ScriptAddressWarnInspector:

   • Defined a new revm::Inspector implementation named ScriptAddressWarnInspector within crates/evm/evm/src/inspectors/stack.rs.
   • This inspector implements the step method, which checks if the currently executing EVM opcode is ADDRESS (0x30).
   • If the ADDRESS opcode is detected, it prints a warning message to stderr: "forge script warning: Usage of \address(this)` detected. Script contracts are ephemeral and their addresses should not be relied upon."`

2. Integrated into InspectorStack:

   • Added an optional address_warn_inspector field to the InspectorStackInner struct.
   • Added a corresponding address_warn boolean flag and a builder method .address_warn_inspector(bool) to InspectorStackBuilder.
   • Updated the InspectorStackBuilder::build method to instantiate ScriptAddressWarnInspector if the address_warn flag is true.
   • Modified the Inspector implementation for InspectorStackRefMut to invoke the step method of the address_warn_inspector if it's present.

3. Enabled for forge script:

   • In crates/script/src/lib.rs, within the _get_runner function (which configures the Executor for scripts), modified the ExecutorBuilder chain to call .address_warn_inspector(true). This ensures the warning inspector is always active during forge script runs.

This approach leverages the existing revm inspector system to passively detect the opcode usage without significantly impacting performance and provides a clear warning directly to the user during script execution.

PR Checklist

• Added Tests
• Added Documentation
• No Breaking changes

[mattsse]

very supportive, some questions.

wdyt @klkvr @grandizzy

[grandizzy]

can you pls add a test too?

[grandizzy]

hey @gap-editor I pushed some cleanups in https://github.com/gap-editor/foundry/commit/8fd0fbf5d06a4e548dcefaa6d480ca087af6e752 pls check. thank you!

[gap-editor]

@klkvr did i do good?

[grandizzy]

@klkvr did i do good?

@gap-editor we should keep the changes in script inspector only and not add custom logic in stack. For this case, since when calling libraries the bytecode address is the library address and not script's contract, we could add one more check to verify that interpreter.contract.bytecode_address is the same as script address, pushed a commit to ad such in 153f984

stale

[grandizzy]

should be rfr, @mattsse @klkvr @DaniPopes pls check (any perf improvement that could be done?)

[zerosnacks]

lgtm! Small notes in regards to output mode for the error

[zerosnacks]

lgtm!

ci error is unrelated

[mattsse]

lgtm

[frolic]

Any chance this behavior can be put behind a flag? We use address(this) a lot throughout MUD to determine the calling context and this error now keeps us from using ~any scripts.

[grandizzy]

Any chance this behavior can be put behind a flag? We use address(this) a lot throughout MUD to determine the calling context and this error now keeps us from using ~any scripts.

yes, that will be available soon with #10408