We'll need it sometime.
Created attachment 654431 [details] [diff] [review] v1
Comment on attachment 654431 [details] [diff] [review] v1 The mapping from the python enum to the C++ enum is a bit weird because we depend on treatAs having the same ordering as the python enum. What if we used just a dict mapping the WebIDL string values to our desired string values, and then just stored the WebIDL string value in the IDLArgument? That would at least nix the ordering dependency. If we wanted to really be cool, we could change our C++ string values to match the WebIDL ones (e.g. replace eStringify with eDefault or something). In the WebIDL parser, I don't think we should raise an error on TreatUndefinedAs=Missing. That's not a problem for the parser per se, and the codegen will already raise an error on it. In the codegen, even if type.nullable() we need to examine treatUndefinedAs, no? In particular, if the argument is "[TreatUndefinedAs=EmptyString] DOMString?" then passing undefined should produce an empty string. r=me with those last two bits fixed and maybe some parser tests added. A followup bug is fine for the string/enum stuff.
Created attachment 654854 [details] [diff] [review] v1.1
Created attachment 654874 [details] [diff] [review] v1.2