Skip to content
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

Add empty ValidMode and Prepare #725

Merged
merged 4 commits into from
Jan 22, 2025
Merged

Add empty ValidMode and Prepare #725

merged 4 commits into from
Jan 22, 2025

Conversation

zhouwfang
Copy link
Member

The next step is to add Verify with optimizations.

#46

@zhouwfang zhouwfang requested a review from ia0 as a code owner January 21, 2025 06:25
@zhouwfang
Copy link
Member Author

Not sure how this PR leads to "thread binary_leb128 has overflowed its stack".

Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stack overflow is because Context::new() and Context::default() are mutually recursive. By using derive you would fix this.

crates/interpreter/src/module.rs Outdated Show resolved Hide resolved
crates/interpreter/src/valid.rs Outdated Show resolved Hide resolved
crates/interpreter/src/valid.rs Outdated Show resolved Hide resolved
crates/interpreter/src/valid.rs Outdated Show resolved Hide resolved
crates/interpreter/src/valid.rs Show resolved Hide resolved
crates/interpreter/src/valid.rs Outdated Show resolved Hide resolved
@zhouwfang zhouwfang requested a review from ia0 January 22, 2025 04:13
refs: &'a mut [bool],
num_global_imports: usize,
}

impl<'a, 'm> ParseData<'a, 'm> {
fn new(context: &'a mut Context<'m>, refs: &'a mut [bool], num_global_imports: usize) -> Self {
impl<'a, 'm, M: ValidMode> ParseData<'a, 'm, M> {
Copy link
Member Author

@zhouwfang zhouwfang Jan 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rust design question: Is there a good reason why the <'a, 'm, M> after ParseData couldn't be omitted? It seems redundant to write them since they could be inferred from the impl<'a, 'm, M: ValidMode>.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because those are different things. ParseData can take arbitrary parameters. If there would be a syntactic sugar it would be the opposite. You have to specify the ParseData parameters, and any free variable would be universally quantified on the impl. But I'm not sure this would help readability.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you give an example where the struct has more parameters than impl? Thanks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example from the standard library.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! "universally quantified on the impl" is a very good description.

crates/interpreter/src/valid.rs Show resolved Hide resolved
refs: &'a mut [bool],
num_global_imports: usize,
}

impl<'a, 'm> ParseData<'a, 'm> {
fn new(context: &'a mut Context<'m>, refs: &'a mut [bool], num_global_imports: usize) -> Self {
impl<'a, 'm, M: ValidMode> ParseData<'a, 'm, M> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because those are different things. ParseData can take arbitrary parameters. If there would be a syntactic sugar it would be the opposite. You have to specify the ParseData parameters, and any free variable would be universally quantified on the impl. But I'm not sure this would help readability.

@ia0 ia0 merged commit 551e9db into google:dev/fast-interp Jan 22, 2025
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants