You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! We're using the stack-graphs crate to do name binding and resolution in Slang with the goal of providing good infrastructure for developing language tools (linters, LSPs, compilers, etc). Our main target language is Solidity, the most popular language for writing smart contracts in Ethereum. We are constructing the stack graph using an adapted version of tree-sitter-graph-builder that works from Slang's parsed CST trees.
Solidity allows multiple inheritance in smart contracts. To resolve calls for constructors and virtual methods, Solidity uses a variant of the C3 linearization algorithm (similar to what Python uses) to deterministically compute an order of contracts to search for implementations. Then if we need to resolve super.foo() we would determine which foo implementation to call using this linearized set.
Is it possible to implement this using stack-graphs somehow? Intuitively I think it's not (at least not during the stack graph construction) because this requires knowing the actual contract type and it's not something that's available syntactically. We construct the graph such that there are valid paths to all inherited implementations and that works fine. The problem is choosing the correct one depending on the context (ie. the actual contract type being compiled). Has anyone encountered this type of problem before and found a good approach to a solution?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi! We're using the
stack-graphs
crate to do name binding and resolution in Slang with the goal of providing good infrastructure for developing language tools (linters, LSPs, compilers, etc). Our main target language is Solidity, the most popular language for writing smart contracts in Ethereum. We are constructing the stack graph using an adapted version oftree-sitter-graph-builder
that works from Slang's parsed CST trees.Solidity allows multiple inheritance in smart contracts. To resolve calls for constructors and virtual methods, Solidity uses a variant of the C3 linearization algorithm (similar to what Python uses) to deterministically compute an order of contracts to search for implementations. Then if we need to resolve
super.foo()
we would determine whichfoo
implementation to call using this linearized set.Is it possible to implement this using stack-graphs somehow? Intuitively I think it's not (at least not during the stack graph construction) because this requires knowing the actual contract type and it's not something that's available syntactically. We construct the graph such that there are valid paths to all inherited implementations and that works fine. The problem is choosing the correct one depending on the context (ie. the actual contract type being compiled). Has anyone encountered this type of problem before and found a good approach to a solution?
Beta Was this translation helpful? Give feedback.
All reactions