feat: mappings from bytecode to contract name#429
Conversation
| code_data = (hexcode, placeholders, contract_name, filename) | ||
| self._build_out_map_code[size].append(code_data) | ||
|
|
||
| def get_by_code(self, bytecode: ForwardRef("ByteVec")) -> tuple: |
There was a problem hiding this comment.
I think the options are:
bytecode: ForwardRef["ByteVec"]bytecode: "ByteVec"bytecode: ByteVec(provided wefrom .bytevec import ByteVec)
My preference would be option (3.), I don't see a problem with importing bytevec from this module -- and going to the definition of ByteVec or unwrap() would work
There was a problem hiding this comment.
if i remember correctly, (2) was complained by ruff, and (3) failed due to circular dependency.
| def eq_except_placeholders(hexcode: str, placeholders): | ||
| last = 0 | ||
| for start, end in placeholders: | ||
| if not eq_bytes(bytecode[last:start], hexcode[2 * last : 2 * start]): |
There was a problem hiding this comment.
I see, we have to do the indexing dance because for immutables placeholders look like 0000...0000 but for libraries they look like __$72fd9f18565b1bf49af679aa1eb458ccdd$__
There was a problem hiding this comment.
yes exactly. library placeholders could be matched using regex, but immutable placeholders are complicated due to ambiguity, especially when surrounded by additional zeros. so i just used indexes for a unified approach.
|
looks very clean to me! this more or less deprecates the existing |
it's correct that this is related to the existing Mapper mechanism, and some functionality overlaps, e.g., get_by_bytecode() used in render_trace() for create txs, which is better to be replaced by the new get_by_code(). |
No description provided.