Add developer_private.js to closure compiler externs

Add developer_private.js to closure compiler externs

Add the developerPrivate extension API to closure compiler externs so that it
can be used in chrome://extensions.

BUG=461039
Committed: https://crrev.com/a9d947d2cb78c4485092a55c255d459fc8e97d94
Cr-Commit-Position: refs/heads/master@{#318088}

[Devlin, 2015-02-25 01:01:41]

rdevlin.cronin@chromium.org changed reviewers:
+ dbeam@chromium.org, tbreisacher@chromium.org

[Devlin, 2015-02-25 01:01:42]

Dan and Tyler, please take a look when you can.  Dan - Tyler and I discussed and
he felt that third_party was an appropriate place for resources that were very
specific to chrome, and unlikely to be used outside of it (though we should at
least mention that in the README).

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
File third_party/closure_compiler/externs/developer_private.js (right):

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:198:
chrome.developerPrivate.onItemStateChanged;
This file omits two functions which take arguments in the form of idl "anys",
which translates to a {?}.  These badly need to be refactored (which can be done
as part of the process of making chrome://extensions use the developer private
API), and I'll update this file when those changes are made, if that's okay.

[Tyler Breisacher (Chromium), 2015-02-25 01:05:37]

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
File third_party/closure_compiler/externs/developer_private.js (right):

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:5: /** @fileoverview
Externs generated from namespace: developerPrivate */
It would be ideal to just not check in generated files and have the output of
the generator be used instead. Of course, setting that up might be tricky so
this is certainly fine for now.

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:50: *  
install_warnings: Array,
this is actually "Array or null" -- maybe the generator should output "!Array"
instead?

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:118: * @param
{Function=} callback
Same here, it's strange for this to be both nullable and optional.

[Devlin, 2015-02-25 16:58:54]

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
File third_party/closure_compiler/externs/developer_private.js (right):

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:50: *  
install_warnings: Array,
On 2015/02/25 01:05:37, Tyler Breisacher (Chromium) wrote:
> this is actually "Array or null" -- maybe the generator should output "!Array"
> instead?

Ah, yeah, this should be !Array, since these aren't optional according to the
IDL.  Fixed (also for other arrays below).

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
third_party/closure_compiler/externs/developer_private.js:118: * @param
{Function=} callback
On 2015/02/25 01:05:36, Tyler Breisacher (Chromium) wrote:
> Same here, it's strange for this to be both nullable and optional.

Weird, absolutely, but also actually accurate.  The extension apis *do* handle
the case of a null callback.  Of course, whether or not we should ever write
that in our own code is dubious - but I'd probably default to allowing it to be
nullable or optional, since both are technically allowed. WDYT?

[Tyler Breisacher (Chromium), 2015-02-25 17:17:33]

On 2015/02/25 16:58:54, Devlin wrote:
>
https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
> File third_party/closure_compiler/externs/developer_private.js (right):
> 
>
https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
> third_party/closure_compiler/externs/developer_private.js:50: *  
> install_warnings: Array,
> On 2015/02/25 01:05:37, Tyler Breisacher (Chromium) wrote:
> > this is actually "Array or null" -- maybe the generator should output
"!Array"
> > instead?
> 
> Ah, yeah, this should be !Array, since these aren't optional according to the
> IDL.  Fixed (also for other arrays below).

But this is auto-generated, right? So if the IDL changes and you re-run the
generation script you'll have to go back and add the !'s again. I guess that's
okay, particularly if you don't expect the IDL to change often. But it would be
better to fix the script (which is not checked in yet.
https://codereview.chromium.org/511943003/). For now, just keep your changes and
add a comment at the top explaining what manual changes were made, I guess.

https://codereview.chromium.org/952823004/diff/1/third_party/closure_compiler...
> third_party/closure_compiler/externs/developer_private.js:118: * @param
> {Function=} callback
> On 2015/02/25 01:05:36, Tyler Breisacher (Chromium) wrote:
> > Same here, it's strange for this to be both nullable and optional.
> 
> Weird, absolutely, but also actually accurate.  The extension apis *do* handle
> the case of a null callback.  Of course, whether or not we should ever write
> that in our own code is dubious - but I'd probably default to allowing it to
be
> nullable or optional, since both are technically allowed. WDYT?

Well, if you're writing the externs by hand, I would probably just write
{!Function=} because there's no reason to pass a null. But since these are
auto-generated by a script, it makes sense for the script to follow the IDL
directly.

[Tyler Breisacher (Chromium), 2015-02-25 17:17:49]

lgtm

[Dan Beam, 2015-02-25 18:40:57]

lgtm though i think the presence of the externs (or awareness of existence)
affects how much these externs would be used internally.  put another way: I
might be too lazy to write these but not to simply use them :).

[Devlin, 2015-02-25 18:52:08]

On 2015/02/25 17:17:33, Tyler Breisacher (Chromium) wrote:
> But this is auto-generated, right? So if the IDL changes and you re-run the
> generation script you'll have to go back and add the !'s again. I guess that's
> okay, particularly if you don't expect the IDL to change often. But it would
be
> better to fix the script (which is not checked in yet.
> https://codereview.chromium.org/511943003/). For now, just keep your changes
and
> add a comment at the top explaining what manual changes were made, I guess.

Yeah, it's kind of a pain right now, but when it's checked in we can fix it. :)
In the meantime, comment added to explain.

[Devlin, 2015-02-25 19:15:55]

The CQ bit was checked by rdevlin.cronin@chromium.org

[Devlin, 2015-02-25 19:15:56]

The patchset sent to the CQ was uploaded after l-g-t-m from dbeam@chromium.org,
tbreisacher@chromium.org
Link to the patchset: https://codereview.chromium.org/952823004/#ps40001 (title:
"comment")

[Devlin, 2015-02-25 19:17:12]

The CQ bit was unchecked by rdevlin.cronin@chromium.org

[Devlin, 2015-02-25 19:18:43]

The CQ bit was checked by rdevlin.cronin@chromium.org

[commit-bot: I haz the power, 2015-02-25 19:20:13]

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

[commit-bot: I haz the power, 2015-02-25 19:31:07]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-02-25 19:32:16]

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