Closed michprev closed 1 year ago
Hi @michprev ! Thanks for your report. Type identifier strings are not part of the public interface and exist just to make function names unambiguous. In particular, these identifiers can change at any time between releases and parsing them is not reliable - depending on your use case, maybe you rather need specific debugging data from the compiler? 13720 and 13157 might be of help. Given that, we won't pursue optimizing those identifiers for decoding and thus we are closing this issue.
Description
Type identifier strings generated in Types.cpp cannot be unambiguously decoded with linear parser because of these escape sequences: https://github.com/ethereum/solidity/blob/49a2db99e69b5608c24064659528dc1d92b21fef/libsolidity/ast/Types.cpp#L262-L271
An example may be
t_mapping$_t_address_$_t_mapping$_t_address_$_t_uint256_$_$
where (parsing from left to right) the last 4 symbols (_$_$
) can be decoded as))
or,$
(this one would end up as an invalid type string, but it would require branching of the parser).Do you have an example implementation of a type identifier strings decoder?
Environment