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
{{ message }}
Repository navigation
handleBracketingOperators (src/support/string.h) is broken, and list parsing in asyncify is not functioning correctly. #6047
Hi, I've come across a corner case where asyncify list parsing is failing with an error:
Fatal: Asyncify: failed to parse lists
The list parsing mechanism is attempting to calculate nesting operators from the code:
Handles bracketing in a list initially split by ",", but the list may contain nested ","s. For example, void foo(int, double)
must be kept together because of the "(". Likewise, "{", "<", "[" are handled.
The implementation performs simple nesting counting:
for (constchar c : part) {
if (c == '(' || c == '<' || c == '[' || c == '{') {
nesting++;
} elseif (c == ')' || c == '>' || c == ']' || c == '}') {
nesting--;
}
}
This doesn't work for the function XStream::operator>(int&). Obviously, the nesting will be -1 at the end, and a fatal error will occur.
I don't have an idea on how to easily fix this. Moreover, I've been using asyncify for a long time, and this list format is hard to maintain. I think that using a one-line-one-function file format is much easier to maintain and will not have this issue.
What do you think? Any suggestion how to fix this?
How about if we find a newline, then we assume that we should split by newlines (and do no other nesting computations, as you said)? That would avoid adding a new option.
It appears that -sASYNCIFY_WHITELIST=@file is parsing the file on its own because Binaryen receives the function list as a string, such as func1, func2, func3, instead of a file. Is it possible that the same bug exists on the Emscripten side as well?
I don't think the emscripten side does any parsing of bracketing, but it does expand response files, so @file would turn into the contents of that file. But that can be adjusted on a per-setting basis.
Activity
caiiiycuk commentedon Oct 24, 2023
link to another asyncify parsing problem #5271
caiiiycuk commentedon Oct 24, 2023
I think we can add another option, like
-sASYNCIFY_STRING_DELIM=newline, and if it is present, then use a one-line-one-function file format.kripken commentedon Oct 24, 2023
How about if we find a newline, then we assume that we should split by newlines (and do no other nesting computations, as you said)? That would avoid adding a new option.
caiiiycuk commentedon Oct 24, 2023
It appears that
-sASYNCIFY_WHITELIST=@fileis parsing the file on its own because Binaryen receives the function list as a string, such as func1, func2, func3, instead of a file. Is it possible that the same bug exists on the Emscripten side as well?kripken commentedon Oct 24, 2023
I don't think the emscripten side does any parsing of bracketing, but it does expand response files, so
@filewould turn into the contents of that file. But that can be adjusted on a per-setting basis.Fix WebAssembly#6047,5271: Support one-line-one-function file format …
Fix WebAssembly#6047,5271: Support one-line-one-function file format …
Fix WebAssembly#6047, WebAssembly#5271: Support one-line-one-function…
Fix WebAssembly#6047, WebAssembly#5271: Support one-line-one-function…
Support one-line-one-function file format for asyncify lists (WebAsse…
Support one-line-one-function file format for asyncify lists (WebAsse…