Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
program { 7:9 - 19:1 }
|
|
|
|
program { 21:9 - 21:50 }
|
|
|
|
program { 21:68 - 21:109 }
|
|
|
|
program { 23:9 - 23:50 }
|
|
|
|
program { 23:68 - 23:109 }
|
|
|
|
program { 25:9 - 26:1 }
|
|
|
|
program { 27:13 - 28:1 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "hf1" { 30:21 - 30:38 }
|
|
|
|
function "hf2" { 31:25 - 31:42 }
|
|
|
|
function "hf3" { 32:29 - 32:46 }
|
|
|
|
function "hf4" { 34:21 - 36:9 }
|
|
|
|
function "hf5" { 37:25 - 39:9 }
|
|
|
|
function "hf6" { 40:29 - 42:9 }
|
|
|
|
function "hf7" { 45:13 - 47:5 }
|
|
|
|
function "hf8" { 49:32 - 49:45 }
|
|
|
|
function "hf9" { 49:94 - 49:107 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
|
|
|
|
program { 1:1 - 474:1 }
|
|
|
|
|
|
|
|
On first line:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f0" { 1:112 - 1:266 }
|
|
|
|
function "f0a" { 1:139 - 1:257 }
|
|
|
|
function "f0b" { 1:167 - 1:248 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x0" { 1:292 - 1:476 }
|
|
|
|
function "x0a" { 1:327 - 1:466 }
|
|
|
|
function "x0b" { 1:361 - 1:456 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Functions Declarations in a function:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f1" { 9:16 - 9:113 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f2" { 12:16 - 16:5 }
|
|
|
|
function "f2a" { 14:21 - 14:116 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f3" { 19:16 - 31:5 }
|
|
|
|
function "f3a" { 21:21 - 29:9 }
|
|
|
|
function "f3b" { 23:25 - 27:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f4" { 34:16 - 34:71 }
|
|
|
|
function "f4a" { 34:46 - 34:50 }
|
|
|
|
function "f5" { 36:16 - 36:151 }
|
|
|
|
function "f5a" { 36:46 - 36:141 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "f6" { 38:16 - 38:189 }
|
|
|
|
function "f6a" { 38:46 - 38:179 }
|
|
|
|
function "f6b" { 38:74 - 38:169 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Indented Functions Declarations in a function:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "fi1" { 43:21 - 43:119 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "fi2" { 46:21 - 50:9 }
|
|
|
|
function "fi2a" { 48:26 - 48:122 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "fi3" { 53:21 - 65:9 }
|
|
|
|
function "fi3a" { 55:26 - 63:13 }
|
|
|
|
function "fi3b" { 57:30 - 61:17 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "fi4" { 68:21 - 68:80 }
|
|
|
|
function "fi4a" { 68:53 - 68:57 }
|
|
|
|
function "fi5" { 70:21 - 70:160 }
|
|
|
|
function "fi5a" { 70:53 - 70:149 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "fi6" { 72:21 - 72:201 }
|
|
|
|
function "fi6a" { 72:53 - 72:190 }
|
|
|
|
function "fi6b" { 72:83 - 72:179 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Functions Expressions in a function:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x1" { 77:22 - 77:119 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x2" { 80:22 - 84:5 }
|
|
|
|
function "x2a" { 82:27 - 82:122 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x3" { 87:22 - 99:5 }
|
|
|
|
function "x3a" { 89:27 - 97:9 }
|
|
|
|
function "x3b" { 91:31 - 95:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x4" { 102:22 - 102:83 }
|
|
|
|
function "x4a" { 102:58 - 102:62 }
|
|
|
|
function "x5" { 104:22 - 104:163 }
|
|
|
|
function "x5a" { 104:58 - 104:153 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "x6" { 106:22 - 106:207 }
|
|
|
|
function "x6a" { 106:58 - 106:197 }
|
|
|
|
function "x6b" { 106:92 - 106:187 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Indented Functions Expressions in a function:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "xi1" { 111:27 - 111:125 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "xi2" { 114:27 - 118:9 }
|
|
|
|
function "xi2a" { 116:32 - 116:128 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "xi3" { 121:27 - 133:9 }
|
|
|
|
function "xi3a" { 123:32 - 131:13 }
|
|
|
|
function "xi3b" { 125:36 - 129:17 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "xi4" { 136:27 - 136:92 }
|
|
|
|
function "xi4a" { 136:65 - 136:69 }
|
|
|
|
function "xi5" { 138:27 - 138:172 }
|
|
|
|
function "xi5a" { 138:65 - 138:161 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "xi6" { 140:27 - 140:219 }
|
|
|
|
function "xi6a" { 140:65 - 140:208 }
|
|
|
|
function "xi6b" { 140:101 - 140:197 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Anonymous Function Declaration in a function:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "" { 146:52 - 151:5 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Global eval:
|
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Global Functions Declarations:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gf1" { 161:13 - 161:111 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gf2" { 164:13 - 168:1 }
|
|
|
|
function "gf2a" { 166:18 - 166:114 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gf3" { 171:13 - 183:1 }
|
|
|
|
function "gf3a" { 173:18 - 181:5 }
|
|
|
|
function "gf3b" { 175:22 - 179:9 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gf4" { 186:13 - 186:72 }
|
|
|
|
function "gf4a" { 186:45 - 186:49 }
|
|
|
|
function "gf5" { 188:13 - 188:152 }
|
|
|
|
function "gf5a" { 188:45 - 188:141 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gf6" { 190:13 - 190:193 }
|
|
|
|
function "gf6a" { 190:45 - 190:182 }
|
|
|
|
function "gf6b" { 190:75 - 190:171 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Indented Global Functions Declarations:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gfi1" { 195:18 - 195:117 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gfi2" { 198:18 - 202:5 }
|
|
|
|
function "gfi2a" { 200:23 - 200:120 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gfi3" { 205:18 - 217:5 }
|
|
|
|
function "gfi3a" { 207:23 - 215:9 }
|
|
|
|
function "gfi3b" { 209:27 - 213:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gfi4" { 220:18 - 220:81 }
|
|
|
|
function "gfi4a" { 220:52 - 220:56 }
|
|
|
|
function "gfi5" { 222:18 - 222:161 }
|
|
|
|
function "gfi5a" { 222:52 - 222:149 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gfi6" { 224:18 - 224:205 }
|
|
|
|
function "gfi6a" { 224:52 - 224:193 }
|
|
|
|
function "gfi6b" { 224:84 - 224:181 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Global Functions Expressions:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gx1" { 229:19 - 229:117 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gx2" { 232:19 - 236:1 }
|
|
|
|
function "gx2a" { 234:24 - 234:120 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gx3" { 239:19 - 251:1 }
|
|
|
|
function "gx3a" { 241:24 - 249:5 }
|
|
|
|
function "gx3b" { 243:28 - 247:9 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gx4" { 254:19 - 254:84 }
|
|
|
|
function "gx4a" { 254:57 - 254:61 }
|
|
|
|
function "gx5" { 256:19 - 256:164 }
|
|
|
|
function "gx5a" { 256:57 - 256:153 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gx6" { 258:19 - 258:211 }
|
|
|
|
function "gx6a" { 258:57 - 258:200 }
|
|
|
|
function "gx6b" { 258:93 - 258:189 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Indented Functions Declarations:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gxi1" { 263:24 - 263:123 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gxi2" { 266:24 - 270:5 }
|
|
|
|
function "gxi2a" { 268:29 - 268:126 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gxi3" { 273:24 - 285:5 }
|
|
|
|
function "gxi3a" { 275:29 - 283:9 }
|
|
|
|
function "gxi3b" { 277:33 - 281:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gxi4" { 288:24 - 288:93 }
|
|
|
|
function "gxi4a" { 288:64 - 288:68 }
|
|
|
|
function "gxi5" { 290:24 - 290:173 }
|
|
|
|
function "gxi5a" { 290:64 - 290:161 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "gxi6" { 292:24 - 292:223 }
|
|
|
|
function "gxi6a" { 292:64 - 292:211 }
|
|
|
|
function "gxi6b" { 292:102 - 292:199 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Anonymous Global Function Declarations:
|
2015-07-17 18:48:30 +00:00
|
|
|
function "" { 299:50 - 304:1 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Function Declarations in an eval:
|
|
|
|
eval { 1:1 - 16:7 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "ef1" { 3:17 - 14:5 }
|
|
|
|
function "ef1a" { 5:22 - 12:9 }
|
|
|
|
function "ef1b" { 7:26 - 10:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 1:225 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "ef2" { 1:56 - 1:217 }
|
|
|
|
function "ef2a" { 1:85 - 1:207 }
|
|
|
|
function "ef2b" { 1:115 - 1:197 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 17:8 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "efi1" { 4:18 - 15:5 }
|
|
|
|
function "efi1a" { 6:23 - 13:9 }
|
|
|
|
function "efi1b" { 8:27 - 11:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 1:234 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "efi2" { 1:57 - 1:225 }
|
|
|
|
function "efi2a" { 1:88 - 1:214 }
|
|
|
|
function "efi2b" { 1:120 - 1:203 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
Function Expressions in an eval:
|
|
|
|
eval { 1:1 - 16:7 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "ex1" { 3:23 - 14:5 }
|
|
|
|
function "ex1a" { 5:28 - 12:9 }
|
|
|
|
function "ex1b" { 7:32 - 10:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 1:246 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "ex2" { 1:62 - 1:237 }
|
|
|
|
function "ex2a" { 1:97 - 1:226 }
|
|
|
|
function "ex2b" { 1:133 - 1:215 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 17:8 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "exi1" { 4:24 - 15:5 }
|
|
|
|
function "exi1a" { 6:29 - 13:9 }
|
|
|
|
function "exi1b" { 8:33 - 11:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
eval { 1:1 - 1:255 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "exi2" { 1:63 - 1:245 }
|
|
|
|
function "exi2a" { 1:100 - 1:233 }
|
|
|
|
function "exi2b" { 1:138 - 1:221 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
new Function Object:
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 2:228 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nf1a" { 2:57 - 2:219 }
|
|
|
|
function "nf1b" { 2:87 - 2:209 }
|
|
|
|
function "nf1c" { 2:117 - 2:199 }
|
|
|
|
eval { 1:1 - 1:56 }
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 18:8 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nf2a" { 5:18 - 16:5 }
|
|
|
|
function "nf2b" { 7:22 - 14:9 }
|
|
|
|
function "nf2c" { 9:26 - 12:13 }
|
|
|
|
eval { 1:1 - 1:56 }
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 2:228 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nf1a" { 2:57 - 2:219 }
|
|
|
|
function "nf1b" { 2:87 - 2:209 }
|
|
|
|
function "nf1c" { 2:117 - 2:199 }
|
|
|
|
eval { 1:1 - 1:56 }
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 2:237 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nfi1a" { 2:58 - 2:227 }
|
|
|
|
function "nfi1b" { 2:90 - 2:216 }
|
|
|
|
function "nfi1c" { 2:122 - 2:205 }
|
|
|
|
eval { 1:1 - 1:56 }
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 18:8 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nf2a" { 5:18 - 16:5 }
|
|
|
|
function "nf2b" { 7:22 - 14:9 }
|
|
|
|
function "nf2c" { 9:26 - 12:13 }
|
|
|
|
eval { 1:1 - 1:56 }
|
2018-11-18 19:10:08 +00:00
|
|
|
function "anonymous" { 1:19 - 18:9 }
|
2015-07-17 18:48:30 +00:00
|
|
|
function "nfi2a" { 5:19 - 16:5 }
|
|
|
|
function "nfi2b" { 7:23 - 14:9 }
|
|
|
|
function "nfi2c" { 9:27 - 12:13 }
|
Add tracking of endColumn for Executables.
https://bugs.webkit.org/show_bug.cgi?id=124245.
Reviewed by Geoffrey Garen.
Source/JavaScriptCore:
1. Fixed computation of columns to take into account the startColumn from
<script> tags. Previously, we were only computing the column relative
to the char after the <script> tag. Now, the column number that JSC
computes is always the column number you'll see when viewing the source
in a text editor (assuming the first column position is 1, not 0).
2. Previously, unlinkedExecutables kept the a base-1 startColumn for
ProgramExecutables and EvalExecutables, but uses base-0 columns for
FunctionExecutables. This has been fixed so that they all use base-0
columns. When the executable gets linked, the column is adjusted into
a base-1 value.
3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
m_unlinkedFunctionNameStart because it actually points to the start
column in the name part of the function declaration.
Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
because it points to the first character in the function body. This is
usually '{' except for functions created from "global code" which
excludes its braces. See FunctionExecutable::fromGlobalCode().
The exclusion of braces for the global code case is needed so that
computed start and end columns will more readily map to what a JS
developer would expect them to be. Otherwise, the first column of the
function source will not be 1 (includes prepended characters added in
constructFunctionSkippingEvalEnabledCheck()).
Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
end column of the UnlinkedFunctionExecutable.
4. For unlinked executables, end column values are either:
a. Relative to the start of the last line if (last line != first line).
b. Relative to the start column position if (last line == first line).
The second case is needed so that we can add an appropriate adjustment
to the end column value (just like we do for the start column) when we
link the executable.
5. This is not new to this patch, but it worth noting that the lineCount
values used through this patch has the following meaning:
- a lineCount of 0 means the source for this code block is on 1 line.
- a lineCount of N means there are N + l lines of source.
This interpretation is janky, but was present before this patch. We can
clean that up later in another patch.
* JavaScriptCore.xcodeproj/project.pbxproj:
- In order to implement WebCore::Internals::parserMetaData(), we need to
move some seemingly unrelated header files from the Project section to
the Private section so that they can be #include'd by the forwarding
CodeBlock.h from WebCore.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::CodeBlock):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::generateFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
- m_isFromGlobalCode is needed to support the exclusion of the open brace /
prepended code for functions created from "global code".
(JSC::UnlinkedFunctionExecutable::link):
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::create):
(JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
(JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
(JSC::UnlinkedFunctionExecutable::recordParse):
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::endColumn):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionBodyNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionBody):
(JSC::ASTBuilder::setFunctionNameStart):
* parser/Lexer.cpp:
(JSC::::shiftLineTerminator):
- Removed an unused SourceCode Lexer<T>::sourceCode() function.
* parser/Lexer.h:
(JSC::Lexer::positionBeforeLastNewline):
(JSC::Lexer::prevTerminator):
- Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
to exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.cpp:
(JSC::ProgramNode::ProgramNode):
(JSC::ProgramNode::create):
(JSC::EvalNode::EvalNode):
(JSC::EvalNode::create):
(JSC::FunctionBodyNode::FunctionBodyNode):
(JSC::FunctionBodyNode::create):
(JSC::FunctionBodyNode::setEndPosition):
- setEndPosition() is needed to fixed up the end position so that we can
exclude the close brace / appended code for functions created from "global
code".
* parser/Nodes.h:
(JSC::ProgramNode::startColumn):
(JSC::ProgramNode::endColumn):
(JSC::EvalNode::startColumn):
(JSC::EvalNode::endColumn):
(JSC::FunctionBodyNode::setFunctionNameStart):
(JSC::FunctionBodyNode::functionNameStart):
(JSC::FunctionBodyNode::endColumn):
* parser/Parser.cpp:
(JSC::::parseFunctionBody):
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::positionBeforeLastNewline):
(JSC::::parse):
- Subtracted 1 from startColumn here to keep the node column values consistently
base-0. See note 2 above.
(JSC::parse):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionBody):
(JSC::SyntaxChecker::setFunctionNameStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getProgramCodeBlock):
(JSC::CodeCache::getEvalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
* runtime/CodeCache.h:
* runtime/Executable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::FunctionExecutable::FunctionExecutable):
(JSC::ProgramExecutable::initializeGlobalProperties):
(JSC::FunctionExecutable::fromGlobalCode):
* runtime/Executable.h:
(JSC::ExecutableBase::isEvalExecutable):
(JSC::ExecutableBase::isProgramExecutable):
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::endColumn):
(JSC::ScriptExecutable::recordParse):
(JSC::FunctionExecutable::create):
(JSC::FunctionExecutable::bodyIncludesBraces):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionPrototype.cpp:
(JSC::insertSemicolonIfNeeded):
(JSC::functionProtoFuncToString):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock):
Source/WebCore:
Test: js/dom/script-start-end-locations.html
* ForwardingHeaders/bytecode: Added.
* ForwardingHeaders/bytecode/CodeBlock.h: Added.
* WebCore.exp.in:
* testing/Internals.cpp:
(WebCore::GetCallerCodeBlockFunctor::GetCallerCodeBlockFunctor):
(WebCore::GetCallerCodeBlockFunctor::operator()):
(WebCore::GetCallerCodeBlockFunctor::codeBlock):
(WebCore::Internals::parserMetaData):
* testing/Internals.h:
* testing/Internals.idl:
Source/WebKit:
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
- Added an exported symbol to make the Win32 build happy. The Win64 symbol
is currently a copy of the Win32 one. It'll need to be updated if the
mangled symbol is different for Win64.
LayoutTests:
* fast/events/window-onerror2-expected.txt:
* inspector-protocol/debugger/setBreakpoint-actions-expected.txt:
* js/dom/script-start-end-locations-expected.txt: Added.
* js/dom/script-start-end-locations.html: Added.
* js/dom/script-tests/script-start-end-locations.js: Added.
* js/dom/stack-trace-expected.txt:
* js/dom/stack-trace.html:
- Changed tabs to spaces. The tabs were making it hard to visually confirm
the exected column values for 2 functions.
Canonical link: https://commits.webkit.org/142783@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-11-19 21:55:16 +00:00
|
|
|
eval { 1:1 - 1:56 }
|
|
|
|
|
|
|
|
PASS successfullyParsed is true
|
|
|
|
|
|
|
|
TEST COMPLETE
|
|
|
|
|