Skip to content

Conversation

@pleath
Copy link
Contributor

@pleath pleath commented Jan 6, 2017

We may redefer a nested function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.

@dilijev
Copy link
Contributor

dilijev commented Jan 6, 2017

You can now resolve the CI issues as described here: #2332 (comment)

…d function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
@chakrabot chakrabot merged commit b04b132 into chakra-core:release/1.4 Jan 9, 2017
chakrabot pushed a commit that referenced this pull request Jan 9, 2017
Merge pull request #2330 from pleath:9871933

We may redefer a nested function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
chakrabot pushed a commit that referenced this pull request Jan 9, 2017
…erral cases.

Merge pull request #2330 from pleath:9871933

We may redefer a nested function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
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.

4 participants