-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace YulString with YulName typedef #15083
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,6 +25,7 @@ | |
|
||
#include <libyul/ASTForward.h> | ||
#include <libyul/YulString.h> | ||
#include <libyul/YulName.h> | ||
|
||
#include <liblangutil/DebugData.h> | ||
|
||
|
@@ -34,16 +35,16 @@ | |
namespace solidity::yul | ||
{ | ||
|
||
using Type = YulString; | ||
using Type = YulName; | ||
|
||
struct TypedName { langutil::DebugData::ConstPtr debugData; YulString name; Type type; }; | ||
struct TypedName { langutil::DebugData::ConstPtr debugData; YulName name; Type type; }; | ||
using TypedNameList = std::vector<TypedName>; | ||
|
||
/// Literal number or string (up to 32 bytes) | ||
enum class LiteralKind { Number, Boolean, String }; | ||
struct Literal { langutil::DebugData::ConstPtr debugData; LiteralKind kind; YulString value; Type type; }; | ||
struct Literal { langutil::DebugData::ConstPtr debugData; LiteralKind kind; YulName value; Type type; }; | ||
/// External / internal identifier or label reference | ||
struct Identifier { langutil::DebugData::ConstPtr debugData; YulString name; }; | ||
struct Identifier { langutil::DebugData::ConstPtr debugData; YulName name; }; | ||
/// Assignment ("x := mload(20:u256)", expects push-1-expression on the right hand | ||
/// side and requires x to occupy exactly one stack slot. | ||
/// | ||
|
@@ -59,7 +60,7 @@ struct VariableDeclaration { langutil::DebugData::ConstPtr debugData; TypedNameL | |
/// Block that creates a scope (frees declared stack variables) | ||
struct Block { langutil::DebugData::ConstPtr debugData; std::vector<Statement> statements; }; | ||
/// Function definition ("function f(a, b) -> (d, e) { ... }") | ||
struct FunctionDefinition { langutil::DebugData::ConstPtr debugData; YulString name; TypedNameList parameters; TypedNameList returnVariables; Block body; }; | ||
struct FunctionDefinition { langutil::DebugData::ConstPtr debugData; YulName name; TypedNameList parameters; TypedNameList returnVariables; Block body; }; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We may have a small problem here. With this change, user-defined functions will use |
||
/// Conditional execution without "else" part. | ||
struct If { langutil::DebugData::ConstPtr debugData; std::unique_ptr<Expression> condition; Block body; }; | ||
/// Switch case or default case | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR seems to be just replacing all instances of
YulString
withYulName
. That's not very useful. The idea was to rename only in those cases whereYulString
is used for identifiers. Those are the cases which we'd want to replace with numeric IDs and we'll do this by switchingYulName
to be some other type.Literal
is a good example of a situation where this must not happen. If you have a string"xyz"
, in the code, it must remain as"xyz"
in the AST. It can't be replaced with some number that we'll only later remap back to the original value.I think we don't want this for
TypedName
either. Types are defined in the dialect so renaming then just in the AST will make us unable to find the right type definition.BTW,
TypeName
is probably a legacy thing at this point and maybe we'll remove it eventually. It is used in the typed Yul dialect, which was an intermediate step in the process of translating the code to Ewasm. Ewasm was dropped and I'm not sure if we'll have any other use for it. In the untyped dialectType
will always be just the default type.As for
FunctionDefinition
, for that one usingYulName
seems correct, though I'm surprised it doesn't use a wholeIdentifier
instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was under the impression you'd wanted to get rid of
YulString
altogether, my bad then.As for
Literal
andTypedName
: How would replacing a string"xyz"
with some identifier and later remapping it be conceptually different from usingYulString
, which replaces the string"xyz"
with a handle (id/hash) to later remap it?