HTMLTreeBuilder should not depend on Frame
https://bugs.webkit.org/show_bug.cgi?id=106256

Reviewed by Eric Seidel.

Source/WebCore:

Rather than have the tree builder ask the Frame whether scripting and
plugins are enabled, we now push that information to the tree builder
via HTMLParserOptions, letting us remove the Frame dependency from the
tree builder.

As a consequence of this change, the "script enabled" bit in the parser
is now locked in when the parser starts. This bit doesn't actually
control when script execute, only how the <noscript> element is parsed.

* html/parser/HTMLDocumentParser.cpp:
(WebCore::tokenizerStateForContextElement):
(WebCore::HTMLDocumentParser::HTMLDocumentParser):
* html/parser/HTMLMetaCharsetParser.cpp:
(WebCore::HTMLMetaCharsetParser::HTMLMetaCharsetParser):
(WebCore::HTMLMetaCharsetParser::checkForMetaCharset):
* html/parser/HTMLParserOptions.cpp:
(WebCore::HTMLParserOptions::HTMLParserOptions):
* html/parser/HTMLParserOptions.h:
(HTMLParserOptions):
(WebCore::HTMLParserOptions::HTMLParserOptions):
* html/parser/HTMLPreloadScanner.cpp:
(WebCore::HTMLPreloadScanner::HTMLPreloadScanner):
(WebCore::HTMLPreloadScanner::processToken):
* html/parser/HTMLTokenizer.cpp:
(WebCore::HTMLTokenizer::HTMLTokenizer):
(WebCore::HTMLTokenizer::nextToken):
(WebCore::HTMLTokenizer::updateStateFor):
* html/parser/HTMLTokenizer.h:
(WebCore::HTMLTokenizer::create):
(HTMLTokenizer):
* html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::processStartTagForInBody):
(WebCore::HTMLTreeBuilder::processStartTagForInHead):
* html/parser/HTMLTreeBuilder.h:
* html/parser/HTMLViewSourceParser.cpp:
(WebCore::HTMLViewSourceParser::HTMLViewSourceParser):
(WebCore::HTMLViewSourceParser::updateTokenizerState):

LayoutTests:

I needed to update this test slightly because now we lock in the
"script enabled" bit for the parser when the parser starts. That means
we'll parse the document in a consistent way even if the "script
enabled" bit gets flipped later.

* fast/parser/noscript-with-javascript-disabled-expected.txt:
* fast/parser/noscript-with-javascript-disabled.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139020 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rationalize closure call heuristics and profiling
https://bugs.webkit.org/show_bug.cgi?id=106270

Source/JavaScriptCore: 

Reviewed by Oliver Hunt.
        
Did a number of things:
        
- CallLinkInfo now remembers if it was ever a closure call, and CallLinkStatus uses
  this. Reduces the likelihood that we will inline a closure call as if it was a
  normal call.
        
- Made InlineCallFrame print inferred function names, and refactored
  CodeBlock::inferredName() to better use FunctionExecutable's API.
        
- Made bytecode dumping print frequent exit sites that led to recompilation.
        
- Made bytecode dumping for op_call and op_construct print what the CallLinkStatus
  saw.
        
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
(CallLinkInfo):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::CodeBlock::dumpBytecodeCommentAndNewLine):
(JSC::CodeBlock::printCallOp):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::dump):
(JSC::InlineCallFrame::inferredName):
(JSC):
(JSC::InlineCallFrame::dumpBriefFunctionInformation):
(JSC::InlineCallFrame::dump):
* bytecode/CodeOrigin.h:
(InlineCallFrame):
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::exitSitesFor):
(DFG):
* bytecode/DFGExitProfile.h:
(ExitProfile):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):

Source/WTF: 

Reviewed by Oliver Hunt.
        
Add a macro to add a method to a class that returns a dumper. Allows you to have
secondary dump() methods for dumping either more or less information.

* wtf/PrintStream.h:
(WTF):

Tools: 

Reviewed by Oliver Hunt.
        
Add ability to use display-profiler-output via a pipe, and add the ability to dump
all generated code ('display *' or 'd *').

* Scripts/display-profiler-output:



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