Turn on UCONFIG_NO_NON_HTML5_CONVERTER to save 100kB

Turn on UCONFIG_NO_NON_HTML5_CONVERTER

UCONFIG_NO_NON_HTML5_CONVERTER was added earlier to our copy of ICU, but
it was never set to 1.  It's my oversight.

1. Turns UCON..CONVERTER on in icu.gyp to drop all the encodings not
   required by the Encoding spec. Dropped encodings include
   UTF-7, BOCU, SCSU, CESU, ISCII, ISO-2022-{KR, CN*}, HZ-GB, ISO-2022-JP's
   other than the original.

2. A lot more sections of the ICU converter code are excluded when
   it's set to 1 including the code for LMB (Lotus Multibyte) encodings and
   X11 compound text encoding (icu common).

3. The character encoding detections for encodings excluded are also disabled.
   (icu i18n)

4. ISO-2022-{KR, CN*} and HZ-GB can be dropped now because Blink treats them
   as replacement encoding. The corresponding alias entries from convertrs.txt
   are also removed.

5. ibm-874 was removed. We used to need it before Blink started, but not any
   more. We only need windows-874.

6. A mistaken in convertrs.txt was corrected : Big5-HKSCS was pointing to
   an old mapping table.

7. Per ICU upstream's suggestion, use '-html' suffix instead of '-html5'
for the encoding tables derived from the WHATWG's encoding spec (ibm866,
shift_jis and euc-jp).

The static 64-bit release build of Chrome on Linux went down from
141,596,616 to 141,491,968 bytes (~ 100 kB reduction). Besides, the icu data
size got smaller by ~ 19 kB ( 10,490,576 to 10,471,008 bytes).

See http://bugs.icu-project.org/trac/ticket/11296 for an upstream bug
I've filed on the issue.


BUG=76328
TEST=browser_tests --gtest_filter="*ncoding*"
TEST=net_unittest --gtest_filter="*ilenameUtil*"
TEST=base_unittests --gtest_filter="*Conv*"
TEST=Blink: fast/encoding/*
TEST=With shared library build, the following has no match.
  nm libicuuc.so | egrep  -i '(bocu|scsu|utf7|2022kr|2022cn|iscii)'
  nm libicui18n.so | egrep  -i '(2022kr|2022cn|ibm42)'
TEST=With static library build, the following has no match.
  nm chrome | egrep -i '(bocu|scsu|utf7|2022kr|2022cn|iscii|ibm42)'

R=jsbell@chromium.org, mark@chromium.org

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

[jungshik at Google, 2014-09-23 00:20:17]

jshin@chromium.org changed reviewers:
+ jsbell@chromium.org, mark@chromium.org

[jungshik at Google, 2014-09-23 21:51:51]

Mark, can you check if the way I changed icu.gyp is correct among other things
(UCONFIG_..*CONVERTER is set in two places in icu.gyp). 

Joshua : this CL will be followed by a CL to align all the single byte encodings
with the WHATWG encoding spec.

[Mark Mentovai, 2014-09-23 21:59:03]

https://codereview.chromium.org/587833004/diff/30001/icu.gyp
File icu.gyp (right):

https://codereview.chromium.org/587833004/diff/30001/icu.gyp#newcode24
icu.gyp:24: 'UCONFIG_NO_NON_HTML5_CONVERSION=1',
Is this needed?

It’s only needed if UCONFIG_NO_NON_HTML5_CONVERSION is visible to headers that
are #included from outside of any ICU targets. Is it?

[jsbell, 2014-09-24 17:44:35]

nothing stood out as obviously wrong in the ICU changes, so those lgtm

There was some inconsistency in whether an #endif has a comment or not, but that
seemed to be based on how many lines were include (i.e. if it fits on one
screen, no need for a comment), which seems fine.

It's great that the upstream ICU is accepting the Encoding Standard changes!
Long term we may want to rename the UCONFIG macro HTML5 -> HTML for consistency
w/ ICU's terminology, but not this CL.

[jungshik at Google, 2014-09-24 20:56:48]

https://codereview.chromium.org/587833004/diff/30001/icu.gyp
File icu.gyp (right):

https://codereview.chromium.org/587833004/diff/30001/icu.gyp#newcode24
icu.gyp:24: 'UCONFIG_NO_NON_HTML5_CONVERSION=1',
On 2014/09/23 21:59:03, Mark Mentovai wrote:
> Is this needed?
> 
> It’s only needed if UCONFIG_NO_NON_HTML5_CONVERSION is visible to headers that
> are #included from outside of any ICU targets. Is it?

That's what I guessed, but was not sure about direct_dep..settings. 

Anyway, no public header depends on UCONFIG_NO...*. So, I will remove that line.
Thanks.

[jungshik at Google, 2014-09-24 21:06:11]

https://codereview.chromium.org/587833004/diff/30001/icu.gyp
File icu.gyp (right):

https://codereview.chromium.org/587833004/diff/30001/icu.gyp#newcode24
icu.gyp:24: 'UCONFIG_NO_NON_HTML5_CONVERSION=1',
On 2014/09/24 20:56:48, Jungshik Shin wrote:
> On 2014/09/23 21:59:03, Mark Mentovai wrote:
> > Is this needed?
> > 
> > It’s only needed if UCONFIG_NO_NON_HTML5_CONVERSION is visible to headers
that
> > are #included from outside of any ICU targets. Is it?
> 
> That's what I guessed, but was not sure about direct_dep..settings. 
> 
> Anyway, no public header depends on UCONFIG_NO...*. So, I will remove that
line.

To be precise, public headers (in source/{common,i18n}/unicode) do depend on
uconfig.h that sets the default value for UCONFIG_NO..*, but
UCONFIG_NO_NON_HTML5_CONVERSION is used only *internally*. So, no need to set it
in 'direct_dependent_settings'.

[jungshik at Google, 2014-09-24 21:07:03]

Thank you, Joshua and Mark. 



Mark, can you take another look?

[jungshik at Google, 2014-09-24 21:08:29]

On 2014/09/24 17:44:35, jsbell wrote:
> nothing stood out as obviously wrong in the ICU changes, so those lgtm
> 
> There was some inconsistency in whether an #endif has a comment or not, but
that
> seemed to be based on how many lines were include (i.e. if it fits on one
> screen, no need for a comment), which seems fine.
> 
> It's great that the upstream ICU is accepting the Encoding Standard changes!
> Long term we may want to rename the UCONFIG macro HTML5 -> HTML for
consistency
> w/ ICU's terminology, but not this CL.

Yeah... I think when I make an upstream patch, I'll end up using
'UCONFIG_ONLY_INCLUDE_HTML_CONVERSION' or sth. like that. We'll see. 
Thank you.

[Mark Mentovai, 2014-09-24 21:10:15]

LGTM (but Rietveld won’t let show me a diff of icu.gyp between patch sets 2 and
3, that’s weird).

[jungshik at Google, 2014-09-24 23:44:11]

On 2014/09/24 21:10:15, Mark Mentovai wrote:
> LGTM (but Rietveld won’t let show me a diff of icu.gyp between patch sets 2
and
> 3, that’s weird).

Thanks. It happened to other files in this CL. For instance, ucnv2022.cpp has
changed between PS #1 and PS #2, but I can't see the diff in Rietveld.

[jungshik at Google, 2014-09-25 00:17:54]

Committed patchset #5 (id:50001) manually as r292131 (presubmit successful).