[Webkit-unassigned] [Bug 149615] [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "super" property

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149615

--- Comment #20 from GSkachkov <gskachkov at gmail.com> ---
Comment on attachment 267799
  --> https://bugs.webkit.org/attachment.cgi?id=267799
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=267799&action=review

>>>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:813
>>>> +                }
>>> 
>>> Nit: I think this whole section of code would be easier to read like this:
>>> ```
>>> if (constructorKind() == ConstructorKind::Derived || isDerivedConstructorContext())
>>>     newDerivedContextType = DerivedContextType::DerivedConstructorContext;
>>> else if (m_codeBlock->isClassContext() || (m_codeBlock->isArrowFunction() && m_derivedContextType == DerivedContextType::DerivedMethodContext))
>>>     newDerivedContextType =  DerivedContextType::DerivedMethodContext
>>> ```
>>> 
>>> Also, why do we need to check "m_codeBlock->isArrowFunction()" when checking "m_derivedContextType == DerivedContextType::DerivedMethodContext"?
>>> When would we have "!m_codeBlock->isArrowFunction() && m_derivedContextType == DerivedContextType::DerivedMethodContext"?
>> 
>> Ohh, I see. We don't need to check m_codeBlock->isArrowFunction() because it already true because of this condition metadata->parseMode() == SourceParseMode::ArrowFunctionMode.
> 
> No, that's not true.
> m_codeBlock is the function we're generating code for. metadata is the inner function we're creating.
> We could have 'metadata->parseMode() == ArrowFunctionMode' but also have m_codeBlock be the global scope or an eval or a regular function.
> The interesting thing here is m_derivedContextType.
> 
> My question is this:
> Does 'm_derivedContextType == DerivedContextType::DerivedMethodSyntax' imply that 'm_codeBlock->isArrowFunction()'?
> If that statement is not true, when would we have 'm_derivedContextType == DerivedContextType::DerivedMethodSyntax' but also have '!m_codeBlock->isArrowFunction()'.
> Is that even possible to have DerivedMethodSyntax when the parent function is not an arrow function? This seems like it should be impossible.

OK I see, I think also it impossible. At time when I start develop this patch I didn't use  parseMode. Now DerivedContextType::DerivedMethodSyntax can be set only for inner arrow function because of the condition metadata->parseMode() == ArrowFunctionMode.

Before idea of this condition was to explicitly allow inherit only of DerivedMethodContext for arrow function and prevent inherit for regular function.
var A = class A { 
      getValue () { 
            return this.value; 
      } 
}; 

var B = class B extends A { 
      getParentValueCase1() { 
            var arrow = () =>  { 
                 var f = function () {
                        debug('There is no super'); 
                        return '';
                 };
                 return f();
            };
            return arrow(); 
      } 
      getParentValueCase2() { 
            var f = function () {
                   debug('There is no super');
                   return '';
            };       
            return f(); 
      } 
};

>>>> Source/JavaScriptCore/debugger/DebuggerCallFrame.cpp:195
>>>> +    EvalExecutable* eval = EvalExecutable::create(callFrame, makeSource(script), codeBlock.isStrictMode(), thisTDZMode, codeBlock.unlinkedCodeBlock()->derivedContextType(), codeBlock.unlinkedCodeBlock()->isArrowFunction(), &variablesUnderTDZ);
>>> 
>>> have you tried this out inside the inspector to make sure it works?
>>> I.e, pausing inside an arrow function and typing in "super" into the console?
>> 
>> Good question. I vent done this. I've checked and it does not work. When I typing 'super' into console it raise exception 'SyntaxError: super is only valid inside functions.' The same behavior inside of the method of class and inside of the arrow function in class method. Looks like bug in class implementation.
> 
> It seems like we should just give our parser the ability to allow this behind some flag. super isn't allowed in 'eval', but it's obviously useful to have this ability inside the debugger when paused inside one of these methods/constructors.

I've created issue https://bugs.webkit.org/show_bug.cgi?id=152597

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151230/e88955bb/attachment-0001.html>