Ensure that Heap.h (not Visitor.h) is #included from Oilpan user code

Ensure that Heap.h (not Visitor.h) is #included from Oilpan user code

Some Oilpan user code included "platform/heap/Visitor.h" instead of
"platform/heap/Heap.h".
This CL adds a preprocessor check to prevent such mistakes.

Original idea from tyoshino@.

BUG=420515

[kouhei (in TOK), 2015-02-16 04:45:12]

kouhei@chromium.org changed reviewers:
+ oilpan-reviews@chromium.org, tyoshino@chromium.org

[haraken, 2015-02-16 04:50:45]

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

[haraken, 2015-02-16 04:50:45]

https://codereview.chromium.org/928033003/diff/1/Source/modules/bluetooth/Blu...
File Source/modules/bluetooth/BluetoothDiscovery.h (right):

https://codereview.chromium.org/928033003/diff/1/Source/modules/bluetooth/Blu...
Source/modules/bluetooth/BluetoothDiscovery.h:9: #include "platform/heap/Heap.h"

Heap.h => Handle.h

https://codereview.chromium.org/928033003/diff/1/Source/platform/heap/Visitor.h
File Source/platform/heap/Visitor.h (right):

https://codereview.chromium.org/928033003/diff/1/Source/platform/heap/Visitor...
Source/platform/heap/Visitor.h:35: # error Do not include
platform/heap/Visitor.h directly. Include platform/heap/Heap.h instead.

Heap.h => Handle.h

I don't fully understand a benefit of disallowing the include. It would be just
an issue of coding convention.

If we want to force some convention, we should force Handle.h (in almost all
cases) and Heap.h (in a limited case where we cannot include Handle.h for some
reason). But still I don't see much benefit in the enforcement.

[kouhei (in TOK), 2015-02-16 04:55:57]

> If we want to force some convention, we should force Handle.h (in almost all
> cases) and Heap.h (in a limited case where we cannot include Handle.h for some
> reason). But still I don't see much benefit in the enforcement.
Ack: Handle.h

The intent was to make it clear for authors/reviewers that using DEFINE_TRACE
macros defined in "Visitor.h",
but not including "Handle.h" instead of "Visitor.h" is recommended.

The "benefit in the enforcement" would be only for consistency.
Other oilpan-reviews@ people: wdyt?

[tyoshino (SeeGerritForStatus), 2015-02-16 06:26:47]

On 2015/02/16 04:55:57, kouhei wrote:
> > If we want to force some convention, we should force Handle.h (in almost all
> > cases) and Heap.h (in a limited case where we cannot include Handle.h for
some
> > reason). But still I don't see much benefit in the enforcement.
> Ack: Handle.h
> 
> The intent was to make it clear for authors/reviewers that using DEFINE_TRACE
> macros defined in "Visitor.h",
> but not including "Handle.h" instead of "Visitor.h" is recommended.
> 
> The "benefit in the enforcement" would be only for consistency.
> Other oilpan-reviews@ people: wdyt?

I'm fine as long as we have some guide somewhere (file or style guide on
dev.chromium.org, etc.) to save reviewers CPU time to resolve conflict with IWYU
rule.

[tyoshino (SeeGerritForStatus), 2016-12-07 10:46:30]

This is obsolete. Closing.

[tyoshino (SeeGerritForStatus), 2016-12-07 10:47:25]

On 2016/12/07 10:46:30, tyoshino wrote:
> This is obsolete. Closing.

Oops. This is not my change. Sorry. But it should be ok to close this.

[tyoshino (SeeGerritForStatus), 2016-12-07 10:47:47]

Description was changed from

==========
Ensure that Heap.h (not Visitor.h) is #included from Oilpan user code

Some Oilpan user code included "platform/heap/Visitor.h" instead of
"platform/heap/Heap.h".
This CL adds a preprocessor check to prevent such mistakes.

Original idea from tyoshino@.

BUG=420515
==========

to

==========
Ensure that Heap.h (not Visitor.h) is #included from Oilpan user code

Some Oilpan user code included "platform/heap/Visitor.h" instead of
"platform/heap/Heap.h".
This CL adds a preprocessor check to prevent such mistakes.

Original idea from tyoshino@.

BUG=420515
==========

[tyoshino (SeeGerritForStatus), 2016-12-07 10:47:47]

tyoshino@chromium.org changed reviewers:
- tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-12-07 10:48:07]

On 2016/12/07 10:47:25, tyoshino wrote:
> On 2016/12/07 10:46:30, tyoshino wrote:
> > This is obsolete. Closing.
> 
> Oops. This is not my change. Sorry. But it should be ok to close this.

Removing myself from R line.