Improve module accessors performance #7
Conversation
Co-authored-by: Zhou Fang <33002388+zhou-w-fang@users.noreply.github.com>
This also fixes some soundness issues in the Rust prelude.
Now that rust-lang/cargo#8010 has been fixed.
| } | ||
| let saved = parser.save(); | ||
| let entry = &self.side_table[x as usize]; | ||
| let range = &entry.parser_range; |
There was a problem hiding this comment.
This has a bug. I have some clue, and you may help clarify the confusion.
The parsing for the code section seemed (before my changes) different between here and in validation. In validation, there is a step of parsing locals embedded in the for loop of functions. But in execution, appending locals is done after (in particular, outside) this Module::func(), e.g. here. The confusion is the parser layouts are different for the code section. Due to the parsing locals step in validation, maybe we need to subtract the length of the locals?
There was a problem hiding this comment.
First, we should probably store core_start in the side table. It's only 4 bytes and saves the loop in Module::section().
Regarding the bug, indeed we should move the let parser_start right after the split_at in valid.rs, because that's what this function was doing.
There was a problem hiding this comment.
By core_start, do you mean code_start?
google#46 --------- Co-authored-by: Zhou Fang <33002388+zhou-w-fang@users.noreply.github.com> Co-authored-by: Julien Cretin <cretin@google.com>
with a bug on restoring parser
38ad38d to
28d29a5
Compare
|
Will continue in google#723 |
google#46