I came across type signatures that should not be in the db in my opinion. Solidity computes selectors for events from a the function/event signature. The types used in the signature are normalized to a set of canonical types e.g. the alias uint is never used to compute selectors (https://docs.soliditylang.org/en/v0.8.18/abi-spec.html#mapping-solidity-to-abi-types) but uint is always replaced with its cannonical form uint256.
I found entries in the database that do not adhere to this standard which leads to ambiguous data.
For example the database contains Issue(uint) as well as Issue(uint256) with different hashes.
It would be cool if types would be substituted according to the standard to avoid confusion.
Thanks, I must have missed that. I'll address this in the rewrite and mark this as "WONTFIX" for the current branch since this issue only really affects the statistics in a negative way.
I came across type signatures that should not be in the db in my opinion. Solidity computes selectors for events from a the function/event signature. The types used in the signature are normalized to a set of canonical types e.g. the alias uint is never used to compute selectors (https://docs.soliditylang.org/en/v0.8.18/abi-spec.html#mapping-solidity-to-abi-types) but uint is always replaced with its cannonical form uint256.
I found entries in the database that do not adhere to this standard which leads to ambiguous data. For example the database contains Issue(uint) as well as Issue(uint256) with different hashes.
It would be cool if types would be substituted according to the standard to avoid confusion.
Thanks for the great work and useful tool.