base::CommandLine: Replace use of wstring with string16.

base::CommandLine: Replace use of wstring with string16.

wstring is deprecated in Chromium. Since all the code in CommandLine
using wstring is Windows-only, string16 is equivalent.

This change is necessary to avoid a presubmit warning when touching the
CommandLine code.

BUG=416785
Committed: https://crrev.com/c9e499ed9ecf90352c57e85811869c70a9bce7cc
Cr-Commit-Position: refs/heads/master@{#297608}

[Matt Giuca, 2014-09-30 00:48:38]

mgiuca@chromium.org changed reviewers:
+ mark@chromium.org

[Mark Mentovai, 2014-09-30 16:37:47]

It would be nice if this was accompanied by something that changed the argument
types at the points of use, too. Some of them are already using string16, but I
bet more of them could be converted.

https://code.google.com/p/chromium/codesearch#search/&q=CommandLine::FromStri...

(ParseFromString is trickier to find, because it’s a non-static method whose
name is also used for other purposes.)

[Matt Giuca, 2014-10-01 01:57:36]

On 2014/09/30 16:37:47, Mark Mentovai wrote:
> It would be nice if this was accompanied by something that changed the
argument
> types at the points of use, too. Some of them are already using string16, but
I
> bet more of them could be converted.

I really don't consider this important. On Windows, wstring and string16 are one
and the same type, and there is a tremendous amount of code that assumes this --
old code uses wstring and new code uses string16 and data is passed between the
two all over the place. Therefore, if I'm changing one interface that uses
wstring (that already has call sites that pass both wstring and string16), to
string16, then I don't see the point of updating all the call sites.

I tracked down every call site to CommandLine::FromString and ParseFromString.
Changing all call sites to use string16 would require that I change other
extremely old APIs to use wstring:
- base::StringPrintf
- installer::ProductState (various methods)
- Find a string16-ish replacement for std::wstringstream

If I did *that* then a reviewer might ask me to update every site that uses the
result of those functions, and so on. This is an intractable thing to try and do
"correctly", and I would argue that as long as the code is Windows-only, it is
fine to assume that wstring and string16 is the same (and if that isn't fine, we
are already screwed).

There is a small number of call sites that actually pass a wstring variable down
into CommandLine::FromString, but I don't think it's worth going and updating
all of them (it will just create inconsistencies in the surrounding code, which
still uses wstring).

(On a personal note, I am only doing this because I want to commit my other CL
which makes CommandLine available to use in ShellUtil, which I need for another
patch which I am only doing to make ShellUtil use CommandLine instead of
manually manipulating strings, which I am only doing because I am refactoring
code in ShellUtil which I need for another feature that I am working on in my
20% time... I am literally four yaks deep and while I am generally happy to do
refactors around code I touch, I don't want to go any deeper.)

[Mark Mentovai, 2014-10-01 03:37:10]

Some of those looked really easy to clean up, but whatever. LGTM.

[Matt Giuca, 2014-10-01 04:11:23]

The CQ bit was checked by mgiuca@chromium.org

[commit-bot: I haz the power, 2014-10-01 04:12:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/602253006/1

[commit-bot: I haz the power, 2014-10-01 07:55:20]

Committed patchset #1 (id:1) as 23b0c62dbd9093053ea83cac74f0b791dc1150f3

[commit-bot: I haz the power, 2014-10-01 07:56:09]

Patchset 1 (id:??) landed as
https://crrev.com/c9e499ed9ecf90352c57e85811869c70a9bce7cc
Cr-Commit-Position: refs/heads/master@{#297608}