Move definition of nested classes that inherit enclosing class outside class definition.
https://bugs.webkit.org/show_bug.cgi?id=113454

Patch by Han Shen <shenhan@google.com> on 2013-04-01
Reviewed by Benjamin Poulain.

HashMap.h does not build on GCC 4.8. Inside this file,
HashMapKeysProxy and HashMapValuesProxy are defined as nested
class inside HashMap - which is legal - the illegal part is that
these 2 classes inherit HashMap, that is the enclosing class, that
causes "reference to in-complete definition" error.

The fix is to move outside the definition of these 2 classes, and
leave only declaration part inside HashMap as is illustrated below -

  template class <typename T>
  class HashMap {
    ... ...
    ... ...
  private:
    class HashMapKeysProxy;

    // ERROR - nested class inherits enclosing class.
    class HashMapKeysProxy : private HashMap {
        ... ...
    };
    ... ...
    ... ...
    class HashMapKeysProxy : private HashMap {
        ... ...
    };
    ... ...
    ... ...
  };

Fixed as below:
  template class <typename T>
  class HashMap {
    ... ...
    ... ...
  private:
    class HashMapKeysProxy;
    class HashMapValuesProxy;

    ... ...
    ... ...
  };

  template <typename T>
  class HashMap<T>::HashMapKeysProxy : private HashMap<T> {
    ... ...
  };

  template <typename T>
  class HashMap<T>::HashMapValuesProxy : private HashMap<T> {
    ... ...
  };

* wtf/HashMap.h:
(HashMap):
(WTF): Factor out nested class definition from enclosing class.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147345 268f45cc-cd09-0410-ab3c-d52691b4dbfc
CSP 1.1: Remove 'type' parameter from CSPDirectiveList::checkSourceAndReportViolation.
https://bugs.webkit.org/show_bug.cgi?id=113502

Reviewed by Adam Barth.

Source/WebCore:

Now that we're passing in 'effectiveDirective', we don't need the 'type'
parameter to generate the proper error message prefix when reporting
violations.

While I'm here, I'll slightly tweak the grammar for the error messages.
Changes are covered via rebaselines of existing tests.

* page/ContentSecurityPolicy.cpp:
(WebCore::CSPDirectiveList::checkSourceAndReportViolation):
    Drop the 'type' parameter. We don't need to pass in a type since
    we're now passing in the 'effectiveDirective'; we can use the latter
    to generate the correct error message prefix.
(WebCore::CSPDirectiveList::allowScriptFromSource):
(WebCore::CSPDirectiveList::allowObjectFromSource):
(WebCore::CSPDirectiveList::allowChildFrameFromSource):
(WebCore::CSPDirectiveList::allowImageFromSource):
(WebCore::CSPDirectiveList::allowStyleFromSource):
(WebCore::CSPDirectiveList::allowFontFromSource):
(WebCore::CSPDirectiveList::allowMediaFromSource):
(WebCore::CSPDirectiveList::allowConnectToSource):
(WebCore::CSPDirectiveList::allowFormAction):
(WebCore::CSPDirectiveList::allowBaseURI):
    Drop the 'type' parameter from the callsites, which has the lovely
    property of allowing us to throw away a bunch of statically allocated
    strings that we don't need anymore.

LayoutTests:

* http/tests/security/contentSecurityPolicy/frame-src-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/frame-src-redirect-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/media-src-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/media-src-track-block-expected.txt:
* http/tests/security/contentSecurityPolicy/object-src-no-url-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/object-src-none-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/object-src-url-blocked-expected.txt:
* http/tests/security/contentSecurityPolicy/style-blocked-expected.txt:
* media/csp-blocks-video-expected.txt:
* platform/chromium/http/tests/security/contentSecurityPolicy/media-src-blocked-expected.txt:
* platform/chromium/media/csp-blocks-video-expected.txt:


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