feat!: Stop supporting console.log selectors with "(u)int" aliases #5764
Conversation
Historically, Hardhat used selectors that computed signatures such as "log(int)", "log(bool,int)", even though the canonical ABI spec defines that the keccak256 should be calculated over the canonical type name, so "int256" or "uint256". This change removes this support as popular tools already support the correct ABI encoding or patch the faulty one, instead.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
🦋 Changeset detectedLatest commit: 82d0c84 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
We support both kinds of More recently, we made I'm not aware of any breakage other than very old Hardhat/Foundry versions, so we wouldn't mind dropping support for it entirely too since it would simplify code and reduce binary size. |
|
Sounds good, thanks for the context! We're waiting for @alcuadrado sign off here; we can then drop the support for the alias signatures moving forward. |
|
Looks good! Thanks, @DaniPopes, for chiming in. |
|
This is blocked until we release a Hardhat version that uses the EDR-powered stack tracing. |
As discussed in Slack, this removes the support for selectors that use the faulty ABI encoding. To reiterate, I searched these selectors in GitHub and I found either someone's Hardhat forks or tools that do not seem to have much usage.
We started shipping correct functions in console.log since bb17b50 (Jul 2022, Hardhat 2.10.2) and it looks like Foundry introduced a patch that normalized our faulty selectors at least since https://github.com/foundry-rs/foundry/pull/6394/files#diff-4726f7deca3fcac31136a3902fd173c49a78f3c3b6322b9bf98c7226b0ebc10a (Nov 2023). I also bumped the changeset to a minor version, as this has a non-zero potential of breaking things.
Because the chances of someone deploying a contract that contains a console.log are slim and even then the value seems to be low, this should be a relatively safe change to make; we can bring it back or re-introduce a grace period then.
@DaniPopes since you worked on this from the Foundry's side of things, do you think there's something else that we'd need to be aware of? Would you still support these fixed selectors in Foundry?