Fix parsing function statements containing invalid tokens #3838
Conversation
dbatyai
added
bug
There was a problem hiding this comment.
If I understand correctly, the problem is there is no scanner info. Just detect that it is not available and do nothing. There is an assert somewhere for "there must be a parse error later", that can be set. Maybe it is specialized for for statements, but can be extended to cover more cases.
| @@ -710,9 +710,8 @@ parser_parse_function_statement (parser_context_t *context_p) /**< context */ | |||
| && context_p->token.lit_location.type == LEXER_IDENT_LITERAL); | |||
|
|
|||
| #if ENABLED (JERRY_ES2015) | |||
| if (context_p->next_scanner_info_p->source_p == context_p->source_p) | |||
There was a problem hiding this comment.
This is the way it should work. If you check the type, but not the source_p, it might refer to something detected later in the source code.
jerry-core/parser/js/js-scanner.c
Outdated
| @@ -1418,6 +1418,7 @@ scanner_scan_statement (parser_context_t *context_p, /**< context */ | |||
| #endif /* ENABLED (JERRY_ES2015) */ | |||
|
|
|||
| scanner_push_literal_pool (context_p, scanner_context_p, status_flags); | |||
| scanner_context_p->active_literal_pool_p->source_p = context_p->source_p; | |||
There was a problem hiding this comment.
The function arguments should set this.
dbatyai
force-pushed
the
func_stmt_invalid_token
branch
2 times, most recently
from
97b04cc to
8c316c7
Compare
dbatyai
force-pushed
the
func_stmt_invalid_token
branch
from
8c316c7 to
6effd1c
Compare
dbatyai
changed the title
| @@ -730,7 +730,10 @@ parser_parse_function_statement (parser_context_t *context_p) /**< context */ | |||
| status_flags |= PARSER_HAS_NON_STRICT_ARG; | |||
| } | |||
|
|
|||
| JERRY_ASSERT (context_p->next_scanner_info_p->type == SCANNER_TYPE_FUNCTION); | |||
| if (context_p->next_scanner_info_p->type != SCANNER_TYPE_FUNCTION) | |||
There was a problem hiding this comment.
Which test triggers this? At this point the ( should be parsed where the scanner info is attached to.
There was a problem hiding this comment.
Ok this is early. Perhaps simply removing this assertion is enough.
There was a problem hiding this comment.
This will be triggered by function a"b. The scanner will call lexer_next_token to consume the left paren, however the unterminated string literal will throw. Since the scanner info would be created after consuming the opening paren, there will be no scanner info for the function.
There was a problem hiding this comment.
Exactly. I think this assert is unnecessary, since no info is created if there will be a parse error before the (. I think there is another assert later which should cover this as well.
Fixes jerryscript-project#3821. JerryScript-DCO-1.0-Signed-off-by: Dániel Bátyai [email protected]
dbatyai
force-pushed
the
func_stmt_invalid_token
branch
from
6effd1c to
14dd68a
Compare
Fixes #3821.