NaCl: Update revision in DEPS, r12488 -> r12497

NaCl: Update revision in DEPS, r12488 -> r12497

This pulls in the following Native Client changes:

r12489: (jfb) Build libc++/libc++abi with HAS_THREAD_LOCAL
r12490: (jvoung) PNaCl: Update LLVM test suite revision in pnacl/COMPONENT_REVISIONS
r12491: (jvoung) Add dashy repos (llvm-test-suite) to pnacl/deps_update.py
r12492: (mseaborn) Add tests for C++ exception types that use virtual base classes
r12493: (jfb) Update TOOL_REVISIONS for PNaCl 12483->12489
r12494: (mseaborn) PNaCl: Update libcxxabi revision in pnacl/COMPONENT_REVISIONS: SJLJ EH support
r12495: (jfb) Mark faultqueue test as broken on ARM.
r12496: (kschimpf) PNaCl: Update LLVM revision in pnacl/COMPONENT_REVISIONS
r12497: (mseaborn) Update PNaCl toolchain revision to r12494 to get SJLJ EH support for libc++

This pulls in libc++ as the default standard C++ library for PNaCl and allows SJLJ EH to work with libc++.

This also fixes out-of-bounds std::map access in nacl_io testing, and correspondingly broken test. All used  pass because libstdc++ just happened to return the expected value when out-of-bounds, but libc++ doesn't return the same thing and the tests now appeared broken.

BUG=none
TEST=nacl_integration
R=binji@chromium.org, dschuff@chromium.org, ronghuawu@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=239294

[JF, 2013-12-06 06:09:52]

chromium/src/third_party/jsoncpp/source/src/lib_json/json_reader.cpp            
                                                                               
is missing <string> and <iostream>, which it both uses in Reader::parse
(apparently jsoncpp's last commit in our repo got rid of unnecessary inclusions
of <iostream> because of the __ioinit symbol). libc++ declares the getline that
this file uses in <string>, and defines it in <iostream>. I'm not sure libc++ is
correct either.

I think the right solution is to fix jsoncpp (since AFAICT it's wrong anyways),
and figure out whether libc++ is wrong separately.

Thoughts?

[JF, 2013-12-06 06:19:48]

+mallinath/ronghuawu for LGTM as OWNERS for jsoncpp: AFAICT this is preventing
the NaCl SDK from building now that we're switching to libc++ for PNaCl instead
of libstdc++.

[JF, 2013-12-06 16:53:28]

https://codereview.chromium.org/98713004/diff/40001/third_party/jsoncpp/overr...
File third_party/jsoncpp/overrides/src/lib_json/json_reader.cpp (right):

https://codereview.chromium.org/98713004/diff/40001/third_party/jsoncpp/overr...
third_party/jsoncpp/overrides/src/lib_json/json_reader.cpp:18: #include
<iostream>
The above two lines are new.

[Derek Schuff, 2013-12-06 17:00:41]

DEPS update LGTM

For jsoncpp, the background is that it uses iostream but doesn't include it,
which is ok with libstdc++'s headers, but is a problem with libc++'s headers.
Since jsoncpp goes into the NaCl SDK and PNaCl is switching to libc++, this
breaks the SDK build.

[JF, 2013-12-06 17:07:03]

> For jsoncpp, the background is that it uses iostream but doesn't include it,
> which is ok with libstdc++'s headers, but is a problem with libc++'s headers.
> Since jsoncpp goes into the NaCl SDK and PNaCl is switching to libc++, this
> breaks the SDK build.

Correct. Mark asked me for a better rationale:

It was removed in 2011 from the commit log (last time that library was updated).

My take is: if you use iostream you have to include it *at least once* and
include iofwd elsewhere. This specific getline overload is *declared* by the
standard in <string>, but AFAICT it can be *defined* anywhere and since it
requires both string and iostream in its signature I think it's fair game to put
it in either (though maybe it shouldn't be in a header, and be in the .a
instead, specialized for char and wchar_t, but then the definition still needs
to be visible for other char types). Especially since including <string>
probably shouldn't mandate <iostream> (bloat and all), but including <iostream>
should mandate <string>.

Mark suggested adding #if __pnacl__ around the new includes to reduce potential
contention here. I agree that's a good idea, but note that the file is still
wrong, just not visibly so.

[JF, 2013-12-06 17:20:50]

Mark asked me to pull in these extra NaCl changes into DEPS so that SJLJ EH also
work with libc++:

r12494: (mseaborn) PNaCl: Update libcxxabi revision in
pnacl/COMPONENT_REVISIONS: SJLJ EH support 
r12495: (jfb) Mark faultqueue test as broken on ARM. 
r12496: (kschimpf) PNaCl: Update LLVM revision in pnacl/COMPONENT_REVISIONS 
r12497: (mseaborn) Update PNaCl toolchain revision to r12494 to get SJLJ EH
support for libc++

[Ronghua Wu (Left Chromium), 2013-12-06 17:36:44]

You need to update jsoncpp.gyp if you add a new override.

[JF, 2013-12-06 17:45:27]

On 2013/12/06 17:36:44, Ronghua Wu wrote:
> You need to update jsoncpp.gyp if you add a new override.

Done.

[Ronghua Wu (Left Chromium), 2013-12-06 23:07:41]

lgtm

[JF, 2013-12-07 00:00:09]

+binji for the nacl_io test fixes: Fix out-of-bounds std::map access in nacl_io
testing, and correspondingly broken test. All used  pass because libstdc++ just
happened to return the expected value when out-of-bounds, but libc++ doesn't
return the same thing and the tests now appeared broken.

[binji, 2013-12-07 00:01:58]

native_client_sdk lgtm

[JF, 2013-12-07 02:06:50]

win_swarm_triggered has an unrelated failure:
BrowserTestWithProfileShortcutManager

win_rel_naclmore also seems unrelated: it fails getting
https://chromium.googlesource.com/external/jsr-305.git

[JF, 2013-12-07 02:55:30]

All else is green, committing.

[binji, 2013-12-07 03:03:18]

Committed patchset #7 manually as r239294 (presubmit successful).