net/websockets: Convert int types from basictypes.h to the ones from stdint.h

net/websockets: Convert int types from basictypes.h to the ones from stdint.h

Now that the supported toolchain has stdint.h, use the integer types
from the standard header file.

Patch generated by the following command lines:

$ git grep -l '\<u\?int[1-9]\+\>' net/websockets/ | xargs sed -i -e 's/\(\<u\?int[1-9]\+\>\)/\1_t/g'
$ git cl format net/websockets

Plus manual inclusion of stdint.h where necessary/appropriate.

BUG=138541, 488550, 539734
TEST=net_unittests
R=ricea@chromium.org,eroman@chromium.org,wtc@chromium.org

Committed: https://crrev.com/8a2c66c243ea4f6689ca1fcca1d25a68825faf22
Cr-Commit-Position: refs/heads/master@{#353814}

[tfarina, 2015-10-12 19:39:59]

Eric, thanks for the regex. I'm really bad at making them :(

I combined yours with Adam's [1-9] to catch everything.

I plan to remove the basictypes.h includes after converting the k(u)int types in
the next patch.

Adam, PTAL.

[eroman, 2015-10-12 21:24:55]

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

[eroman, 2015-10-12 21:24:55]

lgtm

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"
It may be possible to remove basictypes.h in some cases (if the only thing it
was using was uint64 and friends)

[Adam Rice, 2015-10-13 08:32:51]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:7: #include <stdint.h>
I prefer to have a space between the C includes and the C++ includes (but in
practice //net/websockets has a mixture of both, so this is a request, not a
requirement).

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"
On 2015/10/12 21:24:55, eroman wrote:
> It may be possible to remove basictypes.h in some cases (if the only thing it
> was using was uint64 and friends)

I am happy to have it removed in a separate CL (as long as it does get removed).
size_t requires <stdlib.h> and integer limits require <limits.h> or <limits>
depending on whether they are C-style or C++-style.

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_de...
File net/websockets/websocket_deflate_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_de...
net/websockets/websocket_deflate_stream.cc:6: 
Need #include <stdint.h>

[wtc, 2015-10-13 17:12:16]

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

[wtc, 2015-10-13 17:12:17]

LGTM.

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:7: #include <stdint.h>

On 2015/10/13 08:32:51, Adam Rice wrote:
> I prefer to have a space between the C includes and the C++ includes (but in
> practice //net/websockets has a mixture of both, so this is a request, not a
> requirement).

The Style Guide's recommendation changed in this regard. The example code in
the current Style Guide no longer has a blank line between the C and C++ system
header files:

https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Names_and_Or...

So I am afraid that it is hard to ask people to follow the old style guide
recommendation.

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"

On 2015/10/12 21:24:55, eroman wrote:
> It may be possible to remove basictypes.h in some cases (if the only thing it
> was using was uint64 and friends)

Yes, we should take the opportunity to find out if "base/basictypes.h" can be
removed or replaced by "base/macros.h" (for the DISALLOW_COPY_AND_ASSIGN
macro). This requires additional code inspection, but I consider it an integral
part of this work (because I think the goal is to eliminate "base/basictypes.h"
eventually).

[Adam Rice, 2015-10-13 17:21:49]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:7: #include <stdint.h>
On 2015/10/13 17:12:17, wtc wrote:
> 
> On 2015/10/13 08:32:51, Adam Rice wrote:
> > I prefer to have a space between the C includes and the C++ includes (but in
> > practice //net/websockets has a mixture of both, so this is a request, not a
> > requirement).
> 
> The Style Guide's recommendation changed in this regard. The example code in
> the current Style Guide no longer has a blank line between the C and C++
system
> header files:
> 
>
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Names_and_Or...
> 
> So I am afraid that it is hard to ask people to follow the old style guide
> recommendation.

Understood. Request withdrawn.

[tfarina, 2015-10-13 17:50:31]

The CQ bit was checked by tfarina@chromium.org

[tfarina, 2015-10-13 17:50:31]

The patchset sent to the CQ was uploaded after l-g-t-m from eroman@chromium.org,
wtc@chromium.org
Link to the patchset: https://codereview.chromium.org/1399303002/#ps20001
(title: "websocket_deflate_stream.cc")

[tfarina, 2015-10-13 17:50:55]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_de...
File net/websockets/websocket_deflate_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_de...
net/websockets/websocket_deflate_stream.cc:6: 
On 2015/10/13 08:32:51, Adam Rice wrote:
> Need #include <stdint.h>

Done.

[Adam Rice, 2015-10-13 17:51:58]

lgtm

[commit-bot: I haz the power, 2015-10-13 17:57:44]

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

[eroman, 2015-10-13 18:34:26]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"
On 2015/10/13 17:12:17, wtc wrote:
> 
> On 2015/10/12 21:24:55, eroman wrote:
> > It may be possible to remove basictypes.h in some cases (if the only thing
it
> > was using was uint64 and friends)
> 
> Yes, we should take the opportunity to find out if "base/basictypes.h" can be
> removed or replaced by "base/macros.h" (for the DISALLOW_COPY_AND_ASSIGN
> macro). This requires additional code inspection, but I consider it an
integral
> part of this work (because I think the goal is to eliminate
"base/basictypes.h"
> eventually).

This is certainly nice work to do, and can probably be done in bulk over Chrome
code using a tool like IWYU (would be rather labor intensive to do this
manually).

Worth seeing if we can get IWYU to run for Chromium's source code:
http://include-what-you-use.org/

If you are interested there were some bugs on file for this from years ago, not
sure what the latest status is.

[tfarina, 2015-10-13 18:44:32]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"
On 2015/10/13 18:34:26, eroman wrote:
> On 2015/10/13 17:12:17, wtc wrote:
> > 
> > On 2015/10/12 21:24:55, eroman wrote:
> > > It may be possible to remove basictypes.h in some cases (if the only thing
> it
> > > was using was uint64 and friends)
> > 
> > Yes, we should take the opportunity to find out if "base/basictypes.h" can
be
> > removed or replaced by "base/macros.h" (for the DISALLOW_COPY_AND_ASSIGN
> > macro). This requires additional code inspection, but I consider it an
> integral
> > part of this work (because I think the goal is to eliminate
> "base/basictypes.h"
> > eventually).
> 
> This is certainly nice work to do, and can probably be done in bulk over
Chrome
> code using a tool like IWYU (would be rather labor intensive to do this
> manually).
> 
> Worth seeing if we can get IWYU to run for Chromium's source code:
> http://include-what-you-use.org/
> 
> If you are interested there were some bugs on file for this from years ago,
not
> sure what the latest status is.
I talked with Kim Gräsman from iwyu back in March and got some results from
running it on tools/gn, but none were satisfatory. Now it seems there is a new
release from June, so we might give it another try. The integration with our
build system is certainly the complication point. You need to generate a
compilation database first, then pass it to python script, etc.

Something like:

$ ninja -C out/Release -t compdb cxx > out/Release/compile_commands.json
$ iwyu_tool.py -p compile_commands.json ../../tools/gn/gn_main.cc

But I had to manually edit compile_commands.json because of relative paths, a
mess.

Then the tools suggested things like this:
/usr/include/sched.h:30:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^

../../tools/gn/gn_main.cc should add these lines:
#include <debug/map.h>                  // for map
#include <debug/safe_iterator.h>        // for _Safe_iterator, operator!=
#include <stdlib.h>                     // for exit
#include <debug/safe_sequence.tcc>
#include <debug/vector>                 // for vector
#include <map>                          // for _Rb_tree_const_iterator
#include <string>                       // for string, allocator, etc
#include <utility>                      // for pair

Which is far from being good IMO.

[eroman, 2015-10-13 18:59:12]

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
File net/websockets/websocket_basic_stream.cc (right):

https://codereview.chromium.org/1399303002/diff/1/net/websockets/websocket_ba...
net/websockets/websocket_basic_stream.cc:13: #include "base/basictypes.h"
On 2015/10/13 18:44:32, tfarina wrote:
> On 2015/10/13 18:34:26, eroman wrote:
> > On 2015/10/13 17:12:17, wtc wrote:
> > > 
> > > On 2015/10/12 21:24:55, eroman wrote:
> > > > It may be possible to remove basictypes.h in some cases (if the only
thing
> > it
> > > > was using was uint64 and friends)
> > > 
> > > Yes, we should take the opportunity to find out if "base/basictypes.h" can
> be
> > > removed or replaced by "base/macros.h" (for the DISALLOW_COPY_AND_ASSIGN
> > > macro). This requires additional code inspection, but I consider it an
> > integral
> > > part of this work (because I think the goal is to eliminate
> > "base/basictypes.h"
> > > eventually).
> > 
> > This is certainly nice work to do, and can probably be done in bulk over
> Chrome
> > code using a tool like IWYU (would be rather labor intensive to do this
> > manually).
> > 
> > Worth seeing if we can get IWYU to run for Chromium's source code:
> > http://include-what-you-use.org/
> > 
> > If you are interested there were some bugs on file for this from years ago,
> not
> > sure what the latest status is.
> I talked with Kim Gräsman from iwyu back in March and got some results from
> running it on tools/gn, but none were satisfatory. Now it seems there is a new
> release from June, so we might give it another try. The integration with our
> build system is certainly the complication point. You need to generate a
> compilation database first, then pass it to python script, etc.
> 
> Something like:
> 
> $ ninja -C out/Release -t compdb cxx > out/Release/compile_commands.json
> $ iwyu_tool.py -p compile_commands.json ../../tools/gn/gn_main.cc
> 
> But I had to manually edit compile_commands.json because of relative paths, a
> mess.
> 
> Then the tools suggested things like this:
> /usr/include/sched.h:30:10: fatal error: 'stddef.h' file not found
> #include <stddef.h>
>          ^
> 
> ../../tools/gn/gn_main.cc should add these lines:
> #include <debug/map.h>                  // for map
> #include <debug/safe_iterator.h>        // for _Safe_iterator, operator!=
> #include <stdlib.h>                     // for exit
> #include <debug/safe_sequence.tcc>
> #include <debug/vector>                 // for vector
> #include <map>                          // for _Rb_tree_const_iterator
> #include <string>                       // for string, allocator, etc
> #include <utility>                      // for pair
> 
> Which is far from being good IMO.

Thanks for the update! That is too bad, it sounded promising from the project
description :)

[commit-bot: I haz the power, 2015-10-13 19:15:02]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-10-13 19:16:20]

Patchset 2 (id:??) landed as
https://crrev.com/8a2c66c243ea4f6689ca1fcca1d25a68825faf22
Cr-Commit-Position: refs/heads/master@{#353814}