Closed Bug 1243438 Opened 8 years ago Closed 8 years ago

$OBJ/dist/include/mozilla/dom/SubtleCryptoBinding.h:6:10: fatal error: '<unknown>' file not found, with "ac_add_options --disable-eme"

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla47
Tracking Flags:
Tracking Status
firefox47 --- fixed

People

(Reporter: dholbert, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Don't try to include the filename '<unknown>' when including headers for unions that have a built-in typedef they're referenced by
6.53 KB, patch
peterv
: review+
Details | Diff | Splinter Review 
Build error today, with a clobber build:
{
1:36.33 In file included from $OBJ/dom/media/webrtc/Unified_cpp_dom_media_webrtc0.cpp:65:
 1:36.33 In file included from $SRC/dom/media/webrtc/RTCCertificate.cpp:15:
 1:36.33 In file included from $OBJ/dist/include/mozilla/dom/WebCryptoTask.h:14:
 1:36.33 $OBJ/dist/include/mozilla/dom/SubtleCryptoBinding.h:6:10: fatal error: '<unknown>' file not found
 1:36.33 #include "<unknown>"
 1:36.33          ^
}


Indeed, my SubtleCryptoBinding.h file in my objdir starts out like this:
> /* THIS FILE IS AUTOGENERATED FROM SubtleCrypto.webidl BY Codegen.py - DO NOT EDIT */
> 
> #ifndef mozilla_dom_SubtleCryptoBinding_h
> #define mozilla_dom_SubtleCryptoBinding_h
> 
> #include "<unknown>"
> #include "SubtleCryptoBinding.h"
Comparing this generated .h file against the same file in a different build (with a simpler mozconfig), it looks like this #include "<unknown>" line is the only difference. The working build simply does not have that line.
Tim, ideas?
Flags: needinfo?(ttaubert)
Minimal mozconfig which reproduces this:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj
ac_add_options --disable-eme
Summary: $OBJ/dist/include/mozilla/dom/SubtleCryptoBinding.h:6:10: fatal error: '<unknown>' file not found → $OBJ/dist/include/mozilla/dom/SubtleCryptoBinding.h:6:10: fatal error: '<unknown>' file not found, with "ac_add_options --disable-eme"
hg bisect says the first bad revision is:
changeset:   281772:8b255b3ff8d3
user:        Tim Taubert <tim@timtaubert.de>
date:        Tue Jan 26 16:47:41 2016 +0100
summary:     Bug 1200341 - Use BufferSource instead of CryptoOperationData in the SubtleCrypto WebIDL spec r=smaug
Blocks: 1200341
Component: WebRTC → DOM: Security
Keywords: regression
Direct link to regressing changeset, for convenience: https://hg.mozilla.org/mozilla-central/rev/8b255b3ff8d3

That commit seems to be s/CryptoOperationData/BufferSource/ string-replacement in SubtleCrypto.webidl.  For some reason, it introduces this bogus #include into the generated .h file, in builds with --disable-eme. (but nothing beyond that one line is different in the generated .h file)

(This might really be a subtle bug in our python code-generation code, which was merely exposed by this cset...)
This is a codegen bug, yes.

What codegen will do is place the generated struct for a union referenced from just one IDL file in the generated header for that IDL file.  A union referenced from multiple files will go into UnionTypes.h.

When a union is referred to by a typedef, the location of the typedef statement counts as the reference to the union.  Places where the typedef name is used do NOT count as references.  This way if I typedef a union in A.webidl, and then use the typedef in B.webidl and C.webidl, then the actual union struct would go in ABinding.h.  The BBinding and CBinding will need to include ABinding.h.

On the other hand, if I skipped the typedef and just inlined the union in B.webidl and C.webidl, then the union struct would go in UnionTypes.h and ABinding and BBinding would include that header.

That's the background.  Now in this case we have the union (ArrayBufferView or ArrayBuffer).  This union type is referenced from the following places before the fix for bug 1200341:

1)  The CryptoOperationData typedef.
2)  The BufferSource typedef.
3)  MediaKeys.webidl

There are multiple references, so the union struct goes in UnionTypes.h and all is happy.

After bug 1200341, item 1 in that list is gone; it's now using BufferSource.  But there are still two references, so the union struct still goes into UnionTypes.h.

But now if you --disable-eme, we no longer build MediaKeys.webidl (see dom/webidl/moz.build where it's one of the files conditional on MOZ_EME).  So now there is only one reference left, from the BufferSource typedef.  Hence we put the union struct into the generated header for the webidl file that typedef lives in, and include the corresponding header file.  The problem is, this is a builtin typedef.  It doesn't live in any header file at all, but in a string that's fed into the IDL parser before feeding in the .webidl files.  It has a "definition filename" of "<unknown>", which is what we try to use to include the relevant header.  This, of course, fails.
Assignee: nobody → bzbarsky
Blocks: ParisBindings
Component: DOM: Security → DOM
Flags: needinfo?(ttaubert)
(In reply to Boris Zbarsky [:bz] from comment #7)
> That's the background.  Now in this case we have the union (ArrayBufferView
> or ArrayBuffer).

Thanks - that explains why I also get later build errors (in a parallel build w/ compile jobs alongside the failing one from comment 0) like the following:
> error: invalid application of 'sizeof' to an incomplete type 'mozilla::dom::ArrayBufferViewOrArrayBuffer
...and:
> error: member access into incomplete type 'const mozilla::dom::ArrayBufferViewOrArrayBuffer'

I originally thought these were unrelated, but it sounds like they're part of the same problem.
Side note: bug 1200341 (the proximal cause of the build bustage) is nominated for aurora uplift approval.

Hopefully this bug's fix can be suitable (& nominated) for aurora uplift, too, so that bug 1200341 can be uplifted without breaking --disable-eme aurora builds.
[Tracking Requested - why for this release]: Need to backport this if we plan to backport bug 1200341.
tracking-firefox46: --- → ?
(In reply to Daniel Holbert [:dholbert] from comment #9)
> Side note: bug 1200341 (the proximal cause of the build bustage) is
> nominated for aurora uplift approval.
> 
> Hopefully this bug's fix can be suitable (& nominated) for aurora uplift,
> too, so that bug 1200341 can be uplifted without breaking --disable-eme
> aurora builds.

It would be nice to have bug 1200341 on Aurora but only if it doesn't induce extra work. I thought we'd get this for free, if we don't please don't spend extra time on it! :)
And I just remembered that we actually don't need to uplift the .webidl changeset at all. So maybe we should concentrate on fixing Nightly here and only possibly uplift the first of the two changesets.
Note that I have a patch that fixes this bug.  I'm just doing some local testing.
I've verified that this fixed a --disable-eme build and puts the union structs into the right place  there, and has no effect on codegen in an --enable-eme build
Attachment #8712813 - Flags: review?(peterv)
That patch should be quite safe to upload to Aurora if we decide to, btw.
Attachment #8712813 - Flags: review?(peterv) → review+
Tim, how do you want to handle this for Aurora?  This is pretty upliftable, like I said, so whatever you prefer.
Flags: needinfo?(ttaubert)
(In reply to Boris Zbarsky [:bz] from comment #17)
> Tim, how do you want to handle this for Aurora?  This is pretty upliftable,
> like I said, so whatever you prefer.

I think it's fine if we don't uplift, I pushed just the first changeset of bug 1200341 to Aurora.
Flags: needinfo?(ttaubert)
https://hg.mozilla.org/mozilla-central/rev/dbc9072c0d95
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Great, let's not track for 46 then.
tracking-firefox46: ? → ---
Version: unspecified → Trunk
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: