Parse-time nested function escape detection #1416
Conversation
|
@dotnet-bot test Windows arm_debug please |
|
@pleath Thanks, I'm logging into the VMs to take a look. |
|
@dotnet-bot test Windows arm_test please |
|
@pleath Thanks. Looking into these as well. Not sure I'm seeing a pattern yet. |
|
@dotnet-bot test OSX osx_osx_debug_static please. |
| // Parse the operand, make a new node, and look for more | ||
| pnodeT = ParseExpr<buildAST>(opl, NULL, fAllowIn, FALSE, pNameHint, &hintLength, &hintOffset, nullptr); | ||
|
|
||
| // Detect nested function escapes of the pattern "o.f = function(){...}" or "o[s] = function(){...}". |
There was a problem hiding this comment.
will it handle the case as
[o.x] = [function() {...}];
?
There was a problem hiding this comment.
No, it won't. It's not actually meant to be exhaustive, just a cheap pattern-match to catch a certain common class of cases.
|
Other than few clarifications code wise looks good to me. |
function(){...}', 'o[s] = function(){...}', or 'return f(){...}'. Doing so at parse time allows us to disable stack-nested-functions in common cases where an escape is not detected at byte code gen time because of deferred parsing.
|
@dotnet-bot test Windows x86_release please |
|
@dotnet-bot test Windows arm_release please |
|
Thanks @pleath |
Merge pull request #1416 from pleath:8090616 Allow the parser to detect nested function escapes of the pattern 'o.f = function(){...}' or 'o[s] = function(){...}'. Doing so at parse time allows us to disable stack-nested-functions in common cases where an escape is not detected at byte code gen time because of deferred parsing.
6 participants
Allow the parser to detect nested function escapes of the pattern 'o.f = function(){...}' or 'o[s] = function(){...}'. Doing so at parse time allows us to disable stack-nested-functions in common cases where an escape is not detected at byte code gen time because of deferred parsing.