For example, following definition causes an error:
attribute ((double or DOMString) or sequence<(double or DOMString)>) fooAttribute;
$ third_party/WebKit/Tools/Scripts/run-bindings-test
...
Exception: DoubleOrString is not supported as an union member.
We should support it. Actual use case is `BackgroundFetchManager::fetch()`.
While it will block shipping the API, we're quite far away from doing that and I think we can skip on this in the origin trial. That gives us some time to prioritize accordingly :)
+jakearchibald FYI
This should be implemented now.
One thing to note is that nested unions can lead to insanely large names, which currently also mean insanely large file names, such as "NodeOrLongSequenceOrEventOrXMLHttpRequestOrStringOrStringByteStringOrNodeListRecord.cpp".
If you end up having a union name that's too long and causes issues on Windows due to file path limitations, consider adding it to //third_party/WebKit/Source/bindings/scripts/utilities.py's shorten_union_name(). Issue 700907 and issue 611545 are related to this.
I don't think this works as expected yet. Specifically, take a look at the checked in test:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/tests/results/core/NodeOrLongSequenceOrEventOrXMLHttpRequestOrStringOrStringByteStringOrNodeListRecord.h
It uses one of the composite types (ByteStringOrNodeList) without either including or declaring it, so the file can't compile.
I've uploaded two CLs to further illustrate the problem. The first might just be an IWYU issue, but in case of the second we're using the wrong type name, as it would be RequestOrUSVString.
(1) Using nested, local types.
((Request or USVString) or sequence<(Request or USVString)>) requests
---> https://codereview.chromium.org/2743203005
RequestOrUSVStringOrRequestOrUSVStringSequence.h:38: error: use of undeclared identifier 'RequestOrUSVString'
const HeapVector<RequestOrUSVString>& getAsRequestOrUSVStringSequence() const;
(2) Using type definitions defined elsewhere. (As specified.)
(RequestInfo or sequence<RequestInfo>) requests
---> https://codereview.chromium.org/2752543004/
RequestInfoOrRequestInfoSequence.h:31: error: unknown type name 'RequestInfo'
RequestInfo* getAsRequestInfo() const;
I don't think issue 2 , "(RequestInfo or sequence<RequestInfo>) requests" is caused by my CL.
The problem's that RequestInfo is currently manually written and there's no IDL for it, so v8_union.py doesn't know it's supposed to be an interface and doesn't forward-declare the class. If you try any other type from modules/fetch, e.g. Headers, it works as expected. Actually porting RequestInfo to IDL has been in my TODO list for a while, but it's not something I can work on immediately.
I'm still checking issue 1.
None of the issues above is caused by the nested union type support code, it only made them more apparent.
I've filed issue 701410 for (1) and issue 701411 for (2).
Comment 1 by bashi@chromium.org
, Mar 10 2017