Bug 155545

Summary: [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError
Product: WebKit Reporter: GSkachkov <gskachkov>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, keith_miller, mark.lam, msaboff, rniwa, saam, ysuzuki
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 140491    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Archive of layout-test-results from ews114 for mac-yosemite
none
Patch
none
Patch none

GSkachkov
Reported 2016-03-16 10:08:23 PDT
In current version of ES6 class we can't access to the new.target in eval: class A { constructor() { eval('debug(new.target)'); } } new A();//SyntaxError: new.target is only valid inside functions.
Attachments
Patch (42.78 KB, patch)
2016-03-30 12:11 PDT, GSkachkov
no flags
Patch (42.75 KB, patch)
2016-03-30 12:27 PDT, GSkachkov
no flags
Patch (42.96 KB, patch)
2016-03-30 12:50 PDT, GSkachkov
no flags
Patch (43.68 KB, patch)
2016-03-31 12:44 PDT, GSkachkov
no flags
Archive of layout-test-results from ews114 for mac-yosemite (986.57 KB, application/zip)
2016-03-31 13:41 PDT, Build Bot
no flags
Patch (44.49 KB, patch)
2016-04-01 09:56 PDT, GSkachkov
no flags
Patch (44.16 KB, patch)
2016-04-02 10:13 PDT, GSkachkov
no flags
GSkachkov
Comment 1 2016-03-30 12:11:17 PDT
GSkachkov
Comment 2 2016-03-30 12:27:10 PDT
GSkachkov
Comment 3 2016-03-30 12:50:25 PDT
Saam Barati
Comment 4 2016-03-30 14:49:36 PDT
Comment on attachment 275212 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275212&action=review > Source/JavaScriptCore/runtime/CodeCache.cpp:86 > +UnlinkedCodeBlockType* CodeCache::getGlobalCodeBlock(VM& vm, ExecutableType* executable, const SourceCode& source, JSParserBuiltinMode builtinMode, JSParserStrictMode strictMode, ThisTDZMode thisTDZMode, bool, DebuggerMode debuggerMode, ProfilerMode profilerMode, ParserError& error, bool isParantProgramParseMode, const VariableEnvironment* variablesUnderTDZ) Is this truly just the parent? Or is this parent or self is program? i.e, should a Program node be true or false for this? > Source/JavaScriptCore/runtime/CodeCache.cpp:147 > + return getGlobalCodeBlock<UnlinkedModuleProgramCodeBlock>(vm, executable, source, builtinMode, JSParserStrictMode::Strict, ThisTDZMode::CheckIfNeeded, false, debuggerMode, profilerMode, error, false, &emptyParentTDZVariables); It doesn't make sense that this is different from UnlinkedProgramCodeBlock
GSkachkov
Comment 5 2016-03-31 12:44:09 PDT
Build Bot
Comment 6 2016-03-31 13:41:34 PDT
Comment on attachment 275311 [details] Patch Attachment 275311 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1076924 Number of test failures exceeded the failure limit.
Build Bot
Comment 7 2016-03-31 13:41:37 PDT
Created attachment 275321 [details] Archive of layout-test-results from ews114 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
GSkachkov
Comment 8 2016-04-01 09:56:48 PDT
GSkachkov
Comment 9 2016-04-01 10:39:36 PDT
Comment on attachment 275212 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275212&action=review >> Source/JavaScriptCore/runtime/CodeCache.cpp:86 >> +UnlinkedCodeBlockType* CodeCache::getGlobalCodeBlock(VM& vm, ExecutableType* executable, const SourceCode& source, JSParserBuiltinMode builtinMode, JSParserStrictMode strictMode, ThisTDZMode thisTDZMode, bool, DebuggerMode debuggerMode, ProfilerMode profilerMode, ParserError& error, bool isParantProgramParseMode, const VariableEnvironment* variablesUnderTDZ) > > Is this truly just the parent? Or is this parent or self is program? > i.e, should a Program node be true or false for this? In general for Program node it should be does not matter. I've made refactoring in next patch, so it reflect that this value is matter only in eval context. >> Source/JavaScriptCore/runtime/CodeCache.cpp:147 >> + return getGlobalCodeBlock<UnlinkedModuleProgramCodeBlock>(vm, executable, source, builtinMode, JSParserStrictMode::Strict, ThisTDZMode::CheckIfNeeded, false, debuggerMode, profilerMode, error, false, &emptyParentTDZVariables); > > It doesn't make sense that this is different from UnlinkedProgramCodeBlock Fixed
Saam Barati
Comment 10 2016-04-01 17:30:32 PDT
Comment on attachment 275411 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275411&action=review > Source/JavaScriptCore/bytecode/ExecutableInfo.h:34 > +enum class EvalContextType : uint8_t { None, ProgramEvalContextType, FunctionEvalContextType }; It seems like we don't need ProgramEvalContextType. Wy not just use "None" and "FunctionEvalContext"? Style: Also, these name don't need to end with "Type". It can just be "FunctionEvalContext" since this is an "enum class" > Source/JavaScriptCore/parser/Parser.cpp:3866 > + semanticFailIfFalse(currentScope()->isFunction() || (closestParentOrdinaryFunctionNonLexicalScope()->isEvalContext() && closestParentOrdinaryFunctionNonLexicalScope()->evalContextType() == EvalContextType::FunctionEvalContextType), "new.target is only valid inside functions"); Do we really need to check both "isEvalContext() and evalContextType() == ..."? It seems based on your assertion in the constructor it's sufficient to just check that "evalContextType() == FunctionEvalContext" > Source/JavaScriptCore/parser/Parser.h:732 > + unsigned m_evalContextType; This should have type EvalContextType, not unsigned. (The other fields that are unsigned and do similar things with casting should also have their respective types instead of unsigned. We can fix that in a separate patch. I introduced this ugliness in.)
GSkachkov
Comment 11 2016-04-02 10:13:10 PDT
WebKit Commit Bot
Comment 12 2016-04-03 00:59:16 PDT
Comment on attachment 275472 [details] Patch Clearing flags on attachment: 275472 Committed r198980: <http://trac.webkit.org/changeset/198980>
WebKit Commit Bot
Comment 13 2016-04-03 00:59:20 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.