Roll libxml to 2.9.3

Roll libxml to 2.9.3

BUG=587897, 573332
Committed: https://crrev.com/0b5cac87b6b7f1ad537779787240464b0f580a9c
Cr-Commit-Position: refs/heads/master@{#378994}

[dominicc (has gone to gerrit), 2016-03-02 06:54:32]

dominicc@chromium.org changed reviewers:
+ scottmg@chromium.org

[dominicc (has gone to gerrit), 2016-03-02 07:00:12]

PTAL

- Roll libxml to 2.9.3
- Plus some local patches we were carrying
- Plus one upstream fix
- Update README.chromium with all of the above
- Rebaseline one test
- Add me to libxml OWNERS

I disabled LZMA, I assume handling compressed stuff happens elsewhere; I removed
some other mac and wince binary files that our bots were unhappy patching.

I did not roll libxslt yet; the major version is the same and the tests seem to
pass so I figure I can roll that separately.

[scottmg, 2016-03-03 02:59:27]

Thanks! lgtm

I'm not sure about the rebaseline, but I assume that makes some sense to you.

[dominicc (has gone to gerrit), 2016-03-03 05:08:52]

The CQ bit was checked by dominicc@chromium.org

[commit-bot: I haz the power, 2016-03-03 05:09:07]

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

[commit-bot: I haz the power, 2016-03-03 10:34:24]

Committed patchset #5 (id:40001)

[commit-bot: I haz the power, 2016-03-03 10:35:55]

Description was changed from

==========
Roll libxml to 2.9.3

BUG=587897,573332
==========

to

==========
Roll libxml to 2.9.3

BUG=587897,573332

Committed: https://crrev.com/0b5cac87b6b7f1ad537779787240464b0f580a9c
Cr-Commit-Position: refs/heads/master@{#378994}
==========

[commit-bot: I haz the power, 2016-03-03 10:35:57]

Patchset 5 (id:??) landed as
https://crrev.com/0b5cac87b6b7f1ad537779787240464b0f580a9c
Cr-Commit-Position: refs/heads/master@{#378994}

[Sébastien Marchand, 2016-03-03 15:30:58]

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

[Sébastien Marchand, 2016-03-03 15:31:00]

This is breaking the VS2015 builder:
https://build.chromium.org/p/chromium.fyi/builders/Chromium%20Builder/builds/...

:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
error C2220: warning treated as error - no 'object' file generated
c:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
warning C4005: 'snprintf': macro redefinition
c:\b\build\slave\chromium-rel-builder\build\src\third_party\libxml\win32\config.h(99):
note: see previous definition of 'snprintf'

[claudiomdsjr, 2016-03-03 16:31:40]

On 2016/03/03 15:31:00, Sébastien Marchand wrote:
> This is breaking the VS2015 builder:
>
https://build.chromium.org/p/chromium.fyi/builders/Chromium%20Builder/builds/...
> 
>
:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
> error C2220: warning treated as error - no 'object' file generated
>
c:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
> warning C4005: 'snprintf': macro redefinition
>
c:\b\build\slave\chromium-rel-builder\build\src\third_party\libxml\win32\config.h(99):
> note: see previous definition of 'snprintf'

I have a patch for this problem, but this issue seems to be closed and I have
never submitted changes.

What should I do? Could you refer me to a page explaining how to submit a patch
for a case like this one?

[Peter Kasting, 2016-03-03 22:32:51]

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

[Peter Kasting, 2016-03-03 22:32:53]

I tried to auto-revert, but the patch is too big, and I didn't want to go to the
hassle of manually reverting, so I worked around locally :/

This needs fixing though.  Below is some commentary on the problem, but
proceeding onward here would ideally depend on someone raising this issue
upstream while in parallel we patch locally.

https://codereview.chromium.org/1752223002/diff/40001/third_party/libxml/win3...
File third_party/libxml/win32/config.h (left):

https://codereview.chromium.org/1752223002/diff/40001/third_party/libxml/win3...
third_party/libxml/win32/config.h:102: #endif
Removing these two lines is what broke the Visual Studio 2015 build.  If they
are restored, things build correctly.

AFAICT, upstream has both include/win32config.h and win32/VC10/config.h, which
are almost identical except that the latter is missing this change, and there
are minor differences in the #defines atop the files.  The deltas in this patch
set suggest we moved from this being a copy of the former to a copy of the
latter.  I'm not sure whether that's correct.

Honestly, I don't understand precisely what upstream intends the differences
here to be.  I suspect it is an error to have both of these files and have them
only slightly different.  Probably upstream needs to just use one, from one
place.

[Sébastien Marchand, 2016-03-03 22:45:00]

sebmarchand@chromium.org changed reviewers:
+ brucedawson@chromium.org

[Sébastien Marchand, 2016-03-03 22:45:02]

+brucedawson@ fyi (this is breaking your VS2015 builder)

[brucedawson, 2016-03-03 23:50:41]

On 2016/03/03 22:45:02, Sébastien Marchand wrote:
> +brucedawson@ fyi (this is breaking your VS2015 builder)

This is a problem we've hit before. The issue is that VS 2015 actually has a
version of snprintf and we should be using that instead of using a #define to
remap snprintf to _snprintf. A version check is probably what is needed.

Aside: mapping snprintf to _snprintf is a bad idea on VS 2013 as well - the
functions are *not* the same and security bugs can be caused by this.

[brucedawson, 2016-03-03 23:50:46]

On 2016/03/03 22:45:02, Sébastien Marchand wrote:
> +brucedawson@ fyi (this is breaking your VS2015 builder)

This is a problem we've hit before. The issue is that VS 2015 actually has a
version of snprintf and we should be using that instead of using a #define to
remap snprintf to _snprintf. A version check is probably what is needed.

Aside: mapping snprintf to _snprintf is a bad idea on VS 2013 as well - the
functions are *not* the same and security bugs can be caused by this.

[tfarina, 2016-03-05 13:27:59]

On 2016/03/03 16:31:40, claudiomdsjr wrote:
> On 2016/03/03 15:31:00, Sébastien Marchand wrote:
> > This is breaking the VS2015 builder:
> >
>
https://build.chromium.org/p/chromium.fyi/builders/Chromium%20Builder/builds/...
> > 
> >
>
:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
> > error C2220: warning treated as error - no 'object' file generated
> >
>
c:\b\depot_tools\win_toolchain\vs_files\b349b3cc596d5f7e13d649532ddd7e8db39db0cb\win_sdk\include\10.0.10586.0\ucrt\stdio.h(1925):
> > warning C4005: 'snprintf': macro redefinition
> >
>
c:\b\build\slave\chromium-rel-builder\build\src\third_party\libxml\win32\config.h(99):
> > note: see previous definition of 'snprintf'
> 
> I have a patch for this problem, but this issue seems to be closed and I have
> never submitted changes.
> 
> What should I do? Could you refer me to a page explaining how to submit a
patch
> for a case like this one?

If you want to contribute a code to Chromium, please, make sure you read
https://www.chromium.org/developers/how-tos/get-the-code and
https://www.chromium.org/developers/contributing-code. But this is not the place
to discuss this. If you seek further help, you may want to ask on chromium-dev.

[brucedawson, 2016-03-07 19:40:19]

Further comments should go to crbug.com/591920.