Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[Sol->Yul] Add Arity struct (refactor) #8949
Conversation
| #include <string> | ||
|
|
||
| namespace solidity::frontend | ||
| { | ||
|
|
||
| /** | ||
| * Structure that describes arity and co-arity of a function, i.e. the number of its inputs and outputs. |
chriseth
May 19, 2020
Contributor
Maybe clarify: Arity of the yul function representing an internal call to a Solidity function.
Maybe clarify: Arity of the yul function representing an internal call to a Solidity function.
cameel
May 19, 2020
Author
Member
I'll rename it to YulArity. It could actually be used for both Solidity and Yul arity but I guess, if we ever have a need for something like that for Solidity functions it might be better to have separate types.
I'll rename it to YulArity. It could actually be used for both Solidity and Yul arity but I guess, if we ever have a need for something like that for Solidity functions it might be better to have separate types.
cameel
May 19, 2020
Author
Member
Done.
Done.
|
Typo: |
| { | ||
| explicit YulArity(size_t _in, size_t _out): in(_in), out(_out) {} | ||
|
|
||
| static YulArity fromDefinition(FunctionDefinition const& _function); |
chriseth
May 19, 2020
Contributor
Either you extend the description of the struct above or you shortly explain how you get from the Solidity function definiton to the arity of the yul function.
Either you extend the description of the struct above or you shortly explain how you get from the Solidity function definiton to the arity of the yul function.
cameel
May 19, 2020
Author
Member
OK. I'll add more info.
OK. I'll add more info.
cameel
May 19, 2020
Author
Member
Well, maybe it's better to remove it after all. There seem to be many ways to go from a definition to the type. I realized that I should probably include internal somewhere in the name and even then it would still be ambiguous. I could document it but it's probably better to have something like this in the code instead:
YulArity::fromType(*TypeProvider::function(*function, FunctionType::Kind::Internal))
Well, maybe it's better to remove it after all. There seem to be many ways to go from a definition to the type. I realized that I should probably include internal somewhere in the name and even then it would still be ambiguous. I could document it but it's probably better to have something like this in the code instead:
YulArity::fromType(*TypeProvider::function(*function, FunctionType::Kind::Internal))
Thanks. I don't think I can run this spellchecker locally and I'm still trying to figure out how to go around the CircleCI login requirement :) |
d7b434f
into
develop
Based on #8948 which needs to be merged first.
Refactoring changes extracted from #8943 (and before that from #8797). Does not affect functionality.
Related to #6788 and #8485.