HashMapImpl needs to m_buffer.clear() in its constructor

[Filip Pizlo]

Patch forthcoming.

[Ryan Haddad]

*** Bug 161797 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

Created attachment 288405 [details]
possible patch

[WebKit Commit Bot]

Attachment 288405 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/AuxiliaryBarrier.h:40:  Should be indented on a separate line, with the colon or comma first on that line.  [whitespace/indent] [4]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Keith Miller]

Comment on attachment 288405 [details]
possible patch

r=me.

[Filip Pizlo]

Landed in https://trac.webkit.org/changeset/205746

[Mark Lam]

Comment on attachment 288405 [details]
possible patch

View in context: https://bugs.webkit.org/attachment.cgi?id=288405&action=review

> Source/JavaScriptCore/ChangeLog:3
> +        HashMapImpl needs to m_buffer.clear() in its constructor

It's strange that the bug/patch description doesn't seem to match what is being changed.  Am I missing some context here?

[Darin Adler]

Comment on attachment 288405 [details]
possible patch

View in context: https://bugs.webkit.org/attachment.cgi?id=288405&action=review

> Source/JavaScriptCore/ChangeLog:10
> +        This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
> +        itself. That seemed like a good idea because maybe sometimes the user knows better how to
> +        initialize it. But, it's not worth it if it's a constant source of bugs.

One design that allows you to keep the optimization but make the class less error-prone to use is to add a default constructor and a separate constructor that does not initialize that you can invoke explicitly. Something like this:

    enum DoNotInitializeType { DoNotInitialize };

    class AuxiliaryBarrier {
    public:
        AuxiliaryBarrier();
        explicit AuxiliaryBarrier(DoNotInitializeType);
        ...
    };