New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 701411 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
OoO until Feb 4th
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 700370



Sign in to add a comment

bindings: IDL compiler does not expand typedefs before generating union code

Project Member Reported by raphael....@intel.com, Mar 14 2017

Issue description

Spun off https://bugs.chromium.org/p/chromium/issues/detail?id=700225#c8.

Suppose we write the following IDL statements:
  typedef boolean Foo;
  void func((Foo or long) arg);

This will generate two files, FooOrLong.cpp and FooOrLong.h. While we could accept the names still using the Foo typedef, the actual code is broken. FooOrLong.h has the following declarations, for example:

  Foo* getAsFoo() const;
  void setFoo(Foo*);
  static FooOrLong fromFoo(Foo*);
  // ...
  Member<Foo> m_foo;

what's more, the IDL compiler considers "Foo" and "long" two different types, so it even allows one to do something like this:
  typedef boolean Foo;
  void func((Foo or boolean) arg);
 
Status: Started (was: Assigned)
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 16 2017

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

commit 200763220d087ef3ccf735855398ec193db29658
Author: raphael.kubo.da.costa <raphael.kubo.da.costa@intel.com>
Date: Thu Mar 16 08:56:40 2017

bindings: Expand typedefs before generating union files.

Prior to this commit, the IDL compiler was failing to resolve typedefs in
unions before generating new union code. In practice, this meant an IDL
construct such as:

    typedef boolean Foo;
    void func((Foo or long) arg);

Generated FooOrLong.cpp and FooOrLong.h, and "Foo" was considered an IDL
interface instead of a simple bool. Since Foo.cpp and Foo.h do not exist,
and neither does the Foo class, this caused build failures.

We now resolve the typedefs earlier, and in the example above we would now
generate BooleanOrLong.cpp and BooleanOrLong.h, which works as expected.

Fixing this requires a few separate, intertwined changes:
* IdlUnionType.resolve_typedefs() was broken: the |typedefs| argument it
  receives is a dictionary whose keys are typedef names, not
  IdlTypeBase-derived objects, so |typedefs.get()| was always failing and
  returning the original, unresolved member objects.
* CodeGeneratorUnionType actually needs to call resolve_typedefs(). It was
  the only generator class not doing so. The mechanism needs to be different
  from the other classes though, as IdlUnionType is not a type defined in
  idl_definitions.py as is the case for the types handled by the other
  generators. Instead of using TypedefResolver, we simply call the relevant
  parts of it manually.
* The code manually adding union header includes to interfaces and partial
  interfaces has been dropped: there isn't enough information to resolve the
  typedefs at that point, which meant interface .cpp files would include
  FooOrLong.h, while interface .h files include BooleanOrLong.h. The test
  expectations IDL files show a reduction in unneeded includes, and the
  build seems to work fine.

BUG= 701411 
R=bashi@chromium.org,haraken@chromium.org,yukishiino@chromium.org

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

[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/scripts/code_generator_v8.py
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_individual.py
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/scripts/compute_interfaces_info_overall.py
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/scripts/idl_types.py
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/scripts/idl_types_test.py
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/idls/core/TestDictionary.idl
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/idls/core/TestTypedefs.idl
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/idls/modules/TestInterfacePartial3.idl
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/BooleanOrTestCallbackInterface.cpp
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/BooleanOrTestCallbackInterface.h
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/FloatOrBoolean.cpp
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/FloatOrBoolean.h
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/LongOrTestDictionary.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/NodeOrLongSequenceOrEventOrXMLHttpRequestOrStringOrStringByteStringOrNodeListRecord.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/TestDictionary.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/TestDictionary.h
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/UnsignedLongLongOrBooleanOrTestCallbackInterface.cpp
[add] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/UnsignedLongLongOrBooleanOrTestCallbackInterface.h
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestDictionary.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterfaceConstructor.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestSpecialOperations.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestTypedefs.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/V8TestTypedefs.h
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/core/XMLHttpRequestOrString.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterface5.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterfacePartial.cpp
[modify] https://crrev.com/200763220d087ef3ccf735855398ec193db29658/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterfacePartial.h

Status: Fixed (was: Started)
Oh, I forgot to say this doesn't address this specific bit of the bug description:

> what's more, the IDL compiler considers "Foo" and "long" two different types, so it even allows one to do something like this:
>   typedef boolean Foo;
>   void func((Foo or boolean) arg);

this is caused by how v8_union.py detects ambiguous types and is unrelated to typedefs, so I'd rather tackle it separately.

Sign in to add a comment