Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
Committed: https://crrev.com/981a814af98d73032d8f95b174903e34b9720521
Cr-Commit-Position: refs/heads/master@{#381680}

[Yuta Kitamura, 2016-03-17 08:06:32]

The CQ bit was checked by yutak@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-17 08:06:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1813693002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1813693002/1

[Yuta Kitamura, 2016-03-17 08:06:57]

Description was changed from

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
==========

to

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
==========

[Yuta Kitamura, 2016-03-17 08:06:57]

yutak@chromium.org changed reviewers:
+ haraken@chromium.org, tzik@chromium.org

[Yuta Kitamura, 2016-03-17 08:06:58]

yutak@chromium.org changed required reviewers:
+ haraken@chromium.org

[Yuta Kitamura, 2016-03-17 08:07:05]

PTAL

[haraken, 2016-03-17 08:13:56]

LGTM

(ListHashSet is rarely used in the code base.)

[tzik, 2016-03-17 08:38:30]

lgtm

[commit-bot: I haz the power, 2016-03-17 10:04:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-17 10:04:21]

Dry run: This issue passed the CQ dry run.

[Yuta Kitamura, 2016-03-17 10:04:51]

The CQ bit was checked by yutak@chromium.org

[commit-bot: I haz the power, 2016-03-17 10:04:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1813693002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1813693002/1

[commit-bot: I haz the power, 2016-03-17 10:10:00]

Description was changed from

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
==========

to

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
==========

[commit-bot: I haz the power, 2016-03-17 10:10:01]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-17 10:11:47]

Description was changed from

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349
==========

to

==========
Fix ListHashSet::AddResult storing a Node* instead of a ValueType*.

ListHashSet::add() and similar used to return an AddResult value
containing a pointer to ListHashSetNode, instead of an actual value
specified by the user. This is unintuitive, and the users are forced to
append "->m_value" to obtain a pointer to the object they've really
added.

This patch fixes this issue, and giving what the users usually expect.

Interestingly, no production code (outside of tests) made use of
storedValue. LinkedHashSet did not have this issue.

BUG=582349

Committed: https://crrev.com/981a814af98d73032d8f95b174903e34b9720521
Cr-Commit-Position: refs/heads/master@{#381680}
==========

[commit-bot: I haz the power, 2016-03-17 10:11:48]

Patchset 1 (id:??) landed as
https://crrev.com/981a814af98d73032d8f95b174903e34b9720521
Cr-Commit-Position: refs/heads/master@{#381680}