feat: allow supplying function name via forge script --sig

[klkvr]

Motivation

Having script function with many arguments can be annoying as you have to write stuff like forge script --sig run(address,uint256,(address,uint256)...

With this PR if only function name is provided as --sig argument and there is exactly one function with such name in the script ABI, then it will be used. Example above becomes just forge script --sig 'run' 'ARG 1' 'ARG 2'

cc @mds1 I remember we had discussion related to script UX and you mentioned that such UX improvements might result in footguns, so curious to know what you think about this

[mds1]

cc @mds1 I remember we had discussion related to script UX and you mentioned that such UX improvements might result in footguns, so curious to know what you think about this

Hmm any more context here to jog my memory? From an initial read of the PR description this sounds like a nice UX improvement that should be safe. I guess one potential footgun—which seems to be mitigated based on your description—is if you have:

function run(uint x) public {
  run(x, defaultY);
}

function run(uint x, uint y) public {
 // --- snip ---
}

and execute forge script --sig 'run' 'ARG 1' and just forgot to put arg2 and now used the wrong default arg2 value. Whereas previously you need mismatched sig + arg count. But it sounds like this PR prohibits this failure mode anyway if both methods are named run which is ok with me. I would also be ok with inferring/resolving overloads in that case (may not always be possible though, e.g. when methods are run(uint, uint) and run(uint, int))

But otherwise this lgtm and I might need to think more to remember another footgun we discussed

[klkvr]

Hmm any more context here to jog my memory?

I believe it was this one: #5282

forge script --sig 'run' 'ARG 1' and just forgot to put arg2 and now used the wrong default arg2 value.

yeah, that's why we reject duplicates instead of potentialy trying to match by arguments count

I would also be ok with inferring/resolving overloads in that case (may not always be possible though)

I think this PR will encourage users to not have such overloads in scripts, as with this this change you can avoid typing function parameters at all by just having unique names, so no need to have logic for overloads handling imo

[mds1]

Thanks! Ok, I'm onboard with the behavior suggested in this PR and not supporting overloads

[mattsse]

that's a pretty neat UX improvement.

could we test the failure case for overloaded functions in a test?