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.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159520 268f45cc-cd09-0410-ab3c-d52691b4dbfc