Move parser pointer to CPDF_Document

Move parser pointer to CPDF_Document

The CPDF_IndirectObjectHolder has two subclasses, CPDF_Document and
CFDF_Document. The CPDF document requires the parser and the CFDF document
does not. This cl moves the parser pointer up to CPDF_Document.

Committed: https://pdfium.googlesource.com/pdfium/+/260f5fbf3553a96fa49b029cc050220039c30e2a

[dsinclair, 2016-08-16 21:08:47]

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

[commit-bot: I haz the power, 2016-08-16 21:08:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dsinclair, 2016-08-16 21:09:06]

dsinclair@chromium.org changed reviewers:
+ thestig@chromium.org, tsepez@chromium.org

[dsinclair, 2016-08-16 21:09:06]

PTAL.

[Tom Sepez, 2016-08-16 21:15:48]

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:507: auto it =
m_IndirectObjs.find(objnum);
This part (507 - 509) should still be a method on the indirect object holder.

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:520: m_LastObjNum =
std::max(m_LastObjNum, objnum);
This section feels like a method as well.  Document shouldn't be playing with
the holder's members.

[commit-bot: I haz the power, 2016-08-16 21:41:20]

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

[commit-bot: I haz the power, 2016-08-16 21:41:21]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-16 22:22:35]

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:30: bool
InsertIndirectObject(uint32_t objnum, CPDF_Object* pObj);
Can we make this take a unique_ptr argument while we're at it?

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:40:
std::map<uint32_t, CPDF_Object*> m_IndirectObjs;
and can this be a map to unique_ptrs as well?  Yay!

[dsinclair, 2016-08-17 15:57:41]

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

[dsinclair, 2016-08-17 15:57:46]

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:507: auto it =
m_IndirectObjs.find(objnum);
On 2016/08/16 21:15:48, Tom Sepez wrote:
> This part (507 - 509) should still be a method on the indirect object holder. 
 
> 

Done.

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:520: m_LastObjNum =
std::max(m_LastObjNum, objnum);
On 2016/08/16 21:15:48, Tom Sepez wrote:
> This section feels like a method as well.  Document shouldn't be playing with
> the holder's members.

Done.

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:30: bool
InsertIndirectObject(uint32_t objnum, CPDF_Object* pObj);
On 2016/08/16 22:22:35, Tom Sepez wrote:
> Can we make this take a unique_ptr argument while we're at it?

This will be a followup. There are instances were we appear to leak the pObjs
(cpdf_parser.cpp::LoadCrossRefV5) as the Release() method will early exit and
not destroy the object if there is an object number set.  I think we need to get
rid of the Release() calls on cpdf_object before we can safely make this a
unique_ptr.

https://codereview.chromium.org/2253723002/diff/20001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:40:
std::map<uint32_t, CPDF_Object*> m_IndirectObjs;
On 2016/08/16 22:22:34, Tom Sepez wrote:
> and can this be a map to unique_ptrs as well?  Yay!

ditto

[commit-bot: I haz the power, 2016-08-17 15:57:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-17 16:09:58]

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

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

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-17 16:46:45]

Boy, the indirect object holder has some hard-to-describe methods.  Mostly nits.
 Sorry.  Argh.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
File core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1236: FX_BOOL bExistInMap =
m_pDocument->GetIndirectObject(objnum) != nullptr;
nit: the cool kids would write
  bool bExistInMap = !!m_pDocument->GetIndirectObject(objnum);

one of my favorite idioms ...

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1241: CPDF_Object* pObj =
m_pDocument->GetIndirectObjectIfValid(objnum);
Does this introduce a validity check that we previously didn't do?

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cfdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cfdf_document.cpp:92: for (auto it = begin(); it !=
end(); it++)
nit: can we write this as 

  for (const auto& pair : *this)

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:503: CPDF_Object*
CPDF_Document::GetIndirectObjectIfValid(uint32_t objnum) {
nit: maybe GetOrParseIndirectObject(), and de-virtualize.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:25: if (it ==
m_IndirectObjs.end())
nit: maybe ?-operator here as in
  return it != m_IndirectObjs.end() ? it->second : nullptr;

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:38: uint32_t
CPDF_IndirectObjectHolder::AddIndirectObject(CPDF_Object* pObj) {
nit: I wish this name suggested that the obj gets assigned a objnum ... but
drawing a blank.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:57: bool
CPDF_IndirectObjectHolder::InsertIndirectObjectIfHigherGeneration(
nit: More like ReplaceIndirectObjectIfHigherGeneration

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:65: if
(pObj->GetGenNum() <= pOldObj->GetGenNum()) {
nit: combine with &&

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:76: void
CPDF_IndirectObjectHolder::EmplaceIndirectObject(CPDF_Object* pObj) {
nit: more like replace rather than emplace, Emplace to me implies invoking a
ctor which doesn't happen here.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:26: virtual
CPDF_Object* GetIndirectObjectIfValid(uint32_t objnum);
Does this need to be virtual? Can it be const?

[dsinclair, 2016-08-17 16:59:09]

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

[commit-bot: I haz the power, 2016-08-17 16:59:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dsinclair, 2016-08-17 16:59:26]

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
File core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1236: FX_BOOL bExistInMap =
m_pDocument->GetIndirectObject(objnum) != nullptr;
On 2016/08/17 16:46:44, Tom Sepez wrote:
> nit: the cool kids would write
>   bool bExistInMap = !!m_pDocument->GetIndirectObject(objnum);
> 
> one of my favorite idioms ...

I was cool once, but then people stopped wearing onions on their belts and now I
don't know what's cool.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1241: CPDF_Object* pObj =
m_pDocument->GetIndirectObjectIfValid(objnum);
On 2016/08/17 16:46:44, Tom Sepez wrote:
> Does this introduce a validity check that we previously didn't do?

No, because I renamed the method from GetIndirectObject() to
GetIndirectObjectIfValid() to make it clear what was happening. I then added a
new GetIndirectObject() which just got the object.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cfdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cfdf_document.cpp:92: for (auto it = begin(); it !=
end(); it++)
On 2016/08/17 16:46:44, Tom Sepez wrote:
> nit: can we write this as 
> 
>   for (const auto& pair : *this) 

Done.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_document.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_document.cpp:503: CPDF_Object*
CPDF_Document::GetIndirectObjectIfValid(uint32_t objnum) {
On 2016/08/17 16:46:44, Tom Sepez wrote:
> nit: maybe GetOrParseIndirectObject(), and de-virtualize.

Can't as this has to override the version from CPDF_IndirectObjectHolder so we
can do our parse magic. The name is terrible, but I can't come up with anything
better ....

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:25: if (it ==
m_IndirectObjs.end())
On 2016/08/17 16:46:45, Tom Sepez wrote:
> nit: maybe ?-operator here as in
>   return it != m_IndirectObjs.end() ? it->second : nullptr;

Done.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:38: uint32_t
CPDF_IndirectObjectHolder::AddIndirectObject(CPDF_Object* pObj) {
On 2016/08/17 16:46:44, Tom Sepez wrote:
> nit: I wish this name suggested that the obj gets assigned a objnum ... but
> drawing a blank.

Acknowledged. Couldn't come up with anything better either. These methods all
need to be busted apart as they all seem to do multiple things.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:57: bool
CPDF_IndirectObjectHolder::InsertIndirectObjectIfHigherGeneration(
On 2016/08/17 16:46:45, Tom Sepez wrote:
> nit: More like ReplaceIndirectObjectIfHigherGeneration

Done.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:65: if
(pObj->GetGenNum() <= pOldObj->GetGenNum()) {
On 2016/08/17 16:46:44, Tom Sepez wrote:
> nit: combine with &&

Done.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:76: void
CPDF_IndirectObjectHolder::EmplaceIndirectObject(CPDF_Object* pObj) {
On 2016/08/17 16:46:45, Tom Sepez wrote:
> nit: more like replace rather than emplace, Emplace to me implies invoking a
> ctor which doesn't happen here.

Done.

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:26: virtual
CPDF_Object* GetIndirectObjectIfValid(uint32_t objnum);
On 2016/08/17 16:46:45, Tom Sepez wrote:
> Does this need to be virtual? Can it be const?

It does need to be virtual as we have to override it in the CPDF_Document case.
It can't be const since in the CPDF_Document override calls the Emplace method
to add something to m_IndirectObjs.

[Tom Sepez, 2016-08-17 17:04:14]

https://codereview.chromium.org/2253723002/diff/60001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp (right):

https://codereview.chromium.org/2253723002/diff/60001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:47: CPDF_Object* pObj =
GetIndirectObjectIfValid(objnum);
Might this then cause a parse that didn't happen before when the document
overrides this?

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

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

[commit-bot: I haz the power, 2016-08-17 17:12:07]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-17 17:15:31]

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:26: virtual
CPDF_Object* GetIndirectObjectIfValid(uint32_t objnum);
On 2016/08/17 16:59:25, dsinclair wrote:
> On 2016/08/17 16:46:45, Tom Sepez wrote:
> > Does this need to be virtual? Can it be const?
> 
> It does need to be virtual as we have to override it in the CPDF_Document
case.
> It can't be const since in the CPDF_Document override calls the Emplace method
> to add something to m_IndirectObjs.

Alternatively, we could have a virtual ParseIndirectObject() method, that
returns nullptr in this base class, but gets overriden in document.  Then the
duplicated logic in document gets avoided as the non-virtual ..IfValid() then
goes on to call the parse method.

Or, we could add a CPDF_IndirectObjectHolder::Delegate class that implements a
virtual Parse method, and CPDF_IOH ctor takes a delegate or a nullptr as an
argument, and document implements CPDF_IOH::Delegate.

Or ... jeez.

[dsinclair, 2016-08-17 18:14:03]

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

[commit-bot: I haz the power, 2016-08-17 18:14:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dsinclair, 2016-08-17 18:16:44]

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:26: virtual
CPDF_Object* GetIndirectObjectIfValid(uint32_t objnum);
On 2016/08/17 17:15:31, Tom Sepez wrote:
> On 2016/08/17 16:59:25, dsinclair wrote:
> > On 2016/08/17 16:46:45, Tom Sepez wrote:
> > > Does this need to be virtual? Can it be const?
> > 
> > It does need to be virtual as we have to override it in the CPDF_Document
> case.
> > It can't be const since in the CPDF_Document override calls the Emplace
method
> > to add something to m_IndirectObjs.
> 
> Alternatively, we could have a virtual ParseIndirectObject() method, that
> returns nullptr in this base class, but gets overriden in document.  Then the
> duplicated logic in document gets avoided as the non-virtual ..IfValid() then
> goes on to call the parse method.
> 
> Or, we could add a CPDF_IndirectObjectHolder::Delegate class that implements a
> virtual Parse method, and CPDF_IOH ctor takes a delegate or a nullptr as an
> argument, and document implements CPDF_IOH::Delegate.
> 
> Or ... jeez.

Done.

https://codereview.chromium.org/2253723002/diff/60001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp (right):

https://codereview.chromium.org/2253723002/diff/60001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/cpdf_indirect_object_holder.cpp:47: CPDF_Object* pObj =
GetIndirectObjectIfValid(objnum);
On 2016/08/17 17:04:13, Tom Sepez wrote:
> Might this then cause a parse that didn't happen before when the document
> overrides this?

Good catch. Fixed.

[commit-bot: I haz the power, 2016-08-17 18:26:23]

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

[commit-bot: I haz the power, 2016-08-17 18:26:24]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-17 19:15:08]

LGTM.  I think you finally have the right methods.

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_edit/...
File core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp (right):

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1365: for (auto it =
m_pDocument->begin(); it != m_pDocument->end(); it++) {
nit: (const auto& pair : m_pDocument) maybe?

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:31: bool
ReplaceIndirectObjectIfHigherGeneration(uint32_t objnum,
super-super-nit:  I'd order these as

AddIndirectObject()
ReplaceIndirectObject()
ReplaceIndirectObjectIfHigherGeneration()

Kinda odd to see Add sandwiched in the middle.

[dsinclair, 2016-08-17 19:19:53]

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_edit/...
File core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp (right):

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_edit/...
core/fpdfapi/fpdf_edit/fpdf_edit_create.cpp:1365: for (auto it =
m_pDocument->begin(); it != m_pDocument->end(); it++) {
On 2016/08/17 19:15:08, Tom Sepez wrote:
> nit: (const auto& pair : m_pDocument) maybe?

Done.

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_parse...
File core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h (right):

https://codereview.chromium.org/2253723002/diff/80001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:31: bool
ReplaceIndirectObjectIfHigherGeneration(uint32_t objnum,
On 2016/08/17 19:15:08, Tom Sepez wrote:
> super-super-nit:  I'd order these as
> 
> AddIndirectObject()
> ReplaceIndirectObject()
> ReplaceIndirectObjectIfHigherGeneration()
> 
> Kinda odd to see Add sandwiched in the middle.

Done.

[dsinclair, 2016-08-17 19:19:58]

The CQ bit was checked by dsinclair@chromium.org

[dsinclair, 2016-08-17 19:19:59]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/2253723002/#ps100001
(title: "review")

[commit-bot: I haz the power, 2016-08-17 19:20:09]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-17 19:45:30]

Description was changed from

==========
Move parser pointer to CPDF_Document

The CPDF_IndirectObjectHolder has two subclasses, CPDF_Document and
CFDF_Document. The CPDF document requires the parser and the CFDF document
does not. This cl moves the parser pointer up to CPDF_Document.
==========

to

==========
Move parser pointer to CPDF_Document

The CPDF_IndirectObjectHolder has two subclasses, CPDF_Document and
CFDF_Document. The CPDF document requires the parser and the CFDF document
does not. This cl moves the parser pointer up to CPDF_Document.

Committed:
https://pdfium.googlesource.com/pdfium/+/260f5fbf3553a96fa49b029cc050220039c3...
==========

[commit-bot: I haz the power, 2016-08-17 19:45:31]

Committed patchset #6 (id:100001) as
https://pdfium.googlesource.com/pdfium/+/260f5fbf3553a96fa49b029cc050220039c3...

[dsinclair, 2016-08-22 17:15:02]

A revert of this CL (patchset #6 id:100001) has been created in
https://codereview.chromium.org/2266033002/ by dsinclair@chromium.org.

The reason for reverting is: Causing asan issues. See crbug.com/639451..