More trivial cleanupi of ppapi/c/trusted headers

More trivial cleanupi of ppapi/c/trusted headers

BUG= http://code.google.com/p/chromium/issues/detail?id=76271
TEST= run try 
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=92914

[dmichael (off chromium), 2011-07-17 02:00:10]

Mostly pretty good, but there is some odd formatting and there are some lint
errors.

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppb_file_io_...
File ppapi/c/trusted/ppb_file_io_trusted.h (right):

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppb_file_io_...
ppapi/c/trusted/ppb_file_io_trusted.h:43: /* return an error to indicate that
the write is not allowed. */
Why is this a different style?

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h
File ppapi/c/trusted/ppp_broker.h (right):

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h...
ppapi/c/trusted/ppp_broker.h:16: * broker.
Why have you broken up the includes?

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h...
ppapi/c/trusted/ppp_broker.h:20: // {PENDING: undefine PP_EXPORT?}
This comment should probably be C-style

[noelallen1, 2011-07-18 17:51:56]

PTAL

There are a few files, for example Broker, where we define API outside of an
interface.  This is pretty much unsupported in IDL.  We could add support for
it, but for now I went ahead and just used the raw code injection feature
#inline c
#endinl

To add the whole file.  Which is why the header calculations are off (since
there are zero standard IDL definitions in the file).

We should discuss if we want to add support for raw function in the interface
(since they can not be requested by version for example) or if we should find a
different solution.  For the short term however, I believe generating all files
via IDL is the best choice.

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppb_file_io_...
File ppapi/c/trusted/ppb_file_io_trusted.h (right):

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppb_file_io_...
ppapi/c/trusted/ppb_file_io_trusted.h:43: /* return an error to indicate that
the write is not allowed. */
On 2011/07/17 02:00:10, dmichael wrote:
> Why is this a different style?

We have a mix of //, /*, and /** comments in the originals, I went ahead and
fixed this.

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h
File ppapi/c/trusted/ppp_broker.h (right):

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h...
ppapi/c/trusted/ppp_broker.h:16: * broker.
On 2011/07/17 02:00:10, dmichael wrote:
> Why have you broken up the includes?

Because the majority of this file is direct injected code, not generated.  See
bellow.

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h...
ppapi/c/trusted/ppp_broker.h:20: // {PENDING: undefine PP_EXPORT?}
On 2011/07/17 02:00:10, dmichael wrote:
> This comment should probably be C-style

Currently this file is generated via a:
#inline c
#endinc
block.

This is because the generator does not emit #if __GNUC__ >= 4, etc...

Also this is a function without an interface, which is illegal in the IDL.

Our two choices in this case are to leave in an non-generated header, or to use
the #inline block to include raw source.   I figured the later was a better
path.

[dmichael (off chromium), 2011-07-18 18:00:16]

One optional nit. This also seems to have some of the same extra carriage
returns as the other CL. If you want to put off fixing that for another CL, that
would be okay. But of course we should strive for generating lint-friendly code
:-)

So o/w LGTM.

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h
File ppapi/c/trusted/ppp_broker.h (right):

http://codereview.chromium.org/7396002/diff/6002/ppapi/c/trusted/ppp_broker.h...
ppapi/c/trusted/ppp_broker.h:20: // {PENDING: undefine PP_EXPORT?}
On 2011/07/18 17:51:56, noelallen1 wrote:
> On 2011/07/17 02:00:10, dmichael wrote:
> > This comment should probably be C-style
> 
> Currently this file is generated via a:
> #inline c
> #endinc
> block.
> 
> This is because the generator does not emit #if __GNUC__ >= 4, etc...
> 
> Also this is a function without an interface, which is illegal in the IDL.
> 
> Our two choices in this case are to leave in an non-generated header, or to
use
> the #inline block to include raw source.   I figured the later was a better
> path.
Okay, thanks for explaining. It seems we should fix the code that's being placed
inline, then. Optional for this CL.

[dmichael (off chromium), 2011-07-18 21:19:40]

one more nit I noticed, but you can do that in another CL.

LGTM with green trybots.

http://codereview.chromium.org/7396002/diff/4008/ppapi/c/trusted/ppb_file_io_...
File ppapi/c/trusted/ppb_file_io_trusted.h (right):

http://codereview.chromium.org/7396002/diff/4008/ppapi/c/trusted/ppb_file_io_...
ppapi/c/trusted/ppb_file_io_trusted.h:59: */
Is there any way to have comments go in to a separate section that doesn't have
the doxygen style? Maybe even just the way you inject verbatim code or
something.

But in general I'd prefer not to have these TODOs show up in the doxygen output.

Feel free to do in another CL.