search

trufflesuite / truffle

:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat?utm_source=github&utm_medium=referral&utm_campaign=2023_Sep_truffle-sunset-2023_announcement_
MIT License
14.02k stars 2.32k forks source link

Support decoding variables when debugging Vyper #3832

Open haltman-at opened 3 years ago

haltman-at commented 3 years ago

Speaks for itself. This will be a lot of work. We may want to wait on this until Vyper has a more structured AST format (see this Vyper issue), and only support it from that Vyper version forward. If we don't, we may not be able to support everything. In particular, decoding loop variables (!) will be impossible, and it's not clear whether it will be possible to decode mapping keys.

Note that doing this would require expanding the type system in codec. Likely this would be done for just Vyper 0.2.x first, and support for Vyper 0.1.x (with its unit types that were removed in 0.2.x) could be added later.

haltman-at commented 3 years ago

By the way, a note on implementation -- Vyper currently doesn't have type descriptors like Solidity does, which seems like it might present a problem for the way we store mapping keys. However, because Vyper doesn't store struct / array elements inline, we actually don't need the type descriptor; we could just always use "" instead. We only store things by type descriptor in Solidity to solve a problem that arises from struct / array elements being stored inline.

haltman-at commented 3 years ago

One more note: If we're doing this, we might also want to decode Vyper's reentrancy locks. That would probably be follow-on work & a separate issue though? I'll just note it here for now.