"So I actually got some interesting build failures here with the patch I attached and you just reviewed. Interesting in that "make -C $obdir/dom/bindings && make -C $objdir/dom/bindings/test" didn't trigger them (which is why I didn't catch them), but building from toplevel did (!). Using MyTestEnum in my new stuff fixed things."

This sounds a bit like bug 863880.

Yeah, indeed. I fully expect the patch for that bug to fix this.

It sounds like "scoped enums" are the way you are supposed to forward declare enums. You do 'enum class Foo' and then you can use it as long as you don't assume anything about its representation. Cursory research suggests it should even work in VC2010.

Oh, right, it is really just a type def, and apparently you can just forward declare those in the obvious way. Hopefully that will work.

Oops, right, that doesn't work. I'll try a more complex scoped enum based solution tomorrow, defining the underlying enum type inside the nested namespace, then spitting out the typedef for the friendly name the code actually uses, if nobody has a better idea.

Oh, hmm. Right, forward-declaring enums is a huge PITA. :(

I fussed around and got something sort of working, but it looks like I was confused yesterday when I thought VC2010 supports this. According this this chart: http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx they don't support C++11-style forward declaration of enums. I think that means we will have to #include header files that define enums from another .webidl.

OK. In practice, maybe it's not worth worrying about if no one is including enums cross-file yet...

Yeah, I won't worry about this until somebody starts needing it. Fixing this will probably require #including the file for the enum.

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.