Move parser out of IndirectObjectHolder

Move parser out of IndirectObjectHolder

This Cl moves the parser out of the indirect object holder and into the
CPDF_Document where it is used.

Committed: https://pdfium.googlesource.com/pdfium/+/a61c01ea4527dd98699005099e9335a4a842b545

[dsinclair, 2016-08-23 21:05:12]

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

[dsinclair, 2016-08-23 21:05:12]

PTAL.

This is the 3rd and final part of the split CL moving the parser up to the
document.

[dsinclair, 2016-08-23 21:05:16]

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

[commit-bot: I haz the power, 2016-08-23 21:05:22]

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-23 21:17:52]

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

[commit-bot: I haz the power, 2016-08-23 21:17:54]

Dry run: This issue passed the CQ dry run.

[dsinclair, 2016-08-24 13:32:02]

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

[commit-bot: I haz the power, 2016-08-24 13:32:11]

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-24 13:36:41]

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

[commit-bot: I haz the power, 2016-08-24 13:36:42]

Dry run: Try jobs failed on following builders:
  linux_xfa on master.tryserver.client.pdfium (JOB_FAILED,
https://build.chromium.org/p/tryserver.client.pdfium/builders/linux_xfa/build...)

[dsinclair, 2016-08-24 14:06:30]

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

[commit-bot: I haz the power, 2016-08-24 14:06:40]

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-24 14:19:48]

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

[commit-bot: I haz the power, 2016-08-24 14:19:48]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-24 16:13:08]

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

https://codereview.chromium.org/2277433003/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_document.h:131: CPDF_Parser* m_pParser;
can this be CPDF_Parser* const m_pParser?  Or unique_ptr?

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

https://codereview.chromium.org/2277433003/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:46:
std::map<uint32_t, CPDF_Object*> m_IndirectObjs;
Ok, good, not a unique_ptr, I suspect that's where the problem with old cls came
into play where replacing an object would delete an old one that something was
still hanging onto ...

[dsinclair, 2016-08-24 17:20:19]

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

https://codereview.chromium.org/2277433003/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_document.h:131: CPDF_Parser* m_pParser;
On 2016/08/24 16:13:08, Tom Sepez wrote:
> can this be CPDF_Parser* const m_pParser?  Or unique_ptr?  

Followup: https://codereview.chromium.org/2275773003/

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

https://codereview.chromium.org/2277433003/diff/40001/core/fpdfapi/fpdf_parse...
core/fpdfapi/fpdf_parser/include/cpdf_indirect_object_holder.h:46:
std::map<uint32_t, CPDF_Object*> m_IndirectObjs;
On 2016/08/24 16:13:08, Tom Sepez wrote:
> Ok, good, not a unique_ptr, I suspect that's where the problem with old cls
came
> into play where replacing an object would delete an old one that something was
> still hanging onto ...


This wasn't a unique_ptr in the previous attempt. There are weird ownership
patterns around these objects that need to be worked out.

The issue with the old CL was in GetIndirectObject I had a objnum == 0 return
nullptr check. This was causing the issue and that check was moved back into
GetOrParseIndirectObjectg.

[Tom Sepez, 2016-08-24 17:20:56]

lgtm

[dsinclair, 2016-08-24 17:30:59]

The CQ bit was checked by dsinclair@chromium.org

[commit-bot: I haz the power, 2016-08-24 17:31:10]

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-24 17:31:26]

Description was changed from

==========
Move parser out of IndirectObjectHolder

This Cl moves the parser out of the indirect object holder and into the
CPDF_Document where it is used.
==========

to

==========
Move parser out of IndirectObjectHolder

This Cl moves the parser out of the indirect object holder and into the
CPDF_Document where it is used.

Committed:
https://pdfium.googlesource.com/pdfium/+/a61c01ea4527dd98699005099e9335a4a842...
==========

[commit-bot: I haz the power, 2016-08-24 17:31:28]

Committed patchset #3 (id:40001) as
https://pdfium.googlesource.com/pdfium/+/a61c01ea4527dd98699005099e9335a4a842...