A local `executionContext` is duplicated too. 

It looks like it's because one is an attribute and one is a method. Both install_conditionally_enabled_attributes_on_prototype and install_conditionally_enabled_methods spit out unscoped use of `signature` and `executionContext`. 

This actually shows up in the test output for V8TestInterface::preparePrototypeAndInterfaceObject

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterface.cpp?type=cs&q=V8TestInterface::preparePrototypeAndInterfaceObject+package:%5Echromium$&l=2760

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterface.cpp?type=cs&q=V8TestInterface::preparePrototypeAndInterfaceObject+package:%5Echromium$&l=2849

I'd really like to use this to ship a feature in 58, so bumping up to P1.

A naive fix. There would be better ways to fix it though.
https://codereview.chromium.org/2687263002/

Another option is to use a custom Jinja2 filter named "format_remove_duplicates", which does pattern matching and removes duplicates.  When using this filter, be careful about that this filter assumes that all matched lines have the same effect.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/templates/attributes.cpp.tmpl?q=format_remove_duplicates&sq=package:chromium&l=11

Any strong preference between the options?

Can we land the naive fix and refine later, or does it have problems (e.g. is minting a signature twice bad? That's beyond my knowledge of the code)

If bindings owners are happy with the naive fix I'll land the CL. I'll talk to them this afternoon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1397281ab2c5d5e47437363822b7439196851ea3

commit 1397281ab2c5d5e47437363822b7439196851ea3
Author: peria <peria@chromium.org>
Date: Thu Feb 16 09:48:07 2017

Unify a template block 'prepare_prototype_and_interface_object'

This block was defined in interface.cpp.tmpl and partial_interface.cpp.tmpl,
but the difference between them is only to call another
preparePrototypeAndInterfaceObject() of parent class.

Hence this CL merges them and move it to interface_base.cpp.tmpl.
As a side effect, a macro is expanded and another macro is
moved to attributes.cpp.tmpl.

BUG= 690714 

Review-Url: https://codereview.chromium.org/2692343005
Cr-Commit-Position: refs/heads/master@{#450918}

[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/templates/attributes.cpp.tmpl
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/templates/interface.cpp.tmpl
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/templates/interface_base.cpp.tmpl
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/templates/partial_interface.cpp.tmpl
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterface.cpp
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterfaceSecureContext.cpp
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterface5.cpp
[modify] https://crrev.com/1397281ab2c5d5e47437363822b7439196851ea3/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterfacePartial.cpp

https://codereview.chromium.org/2692343006/ is already landed (I'm not sure why it does not post a message here) and it fixes this issue.
Let me close it.