Closed Bug 958576 Opened 10 years ago Closed 10 years ago

Move more things into detail namespaces in bindings code

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

(Whiteboard: [qa-])

Attachments

(2 files)

Fast* dictionary types are already there, but I saw people using AutoSequence.  And FakeDependentString should really go there as well.  Patches coming up.
Note that we can't name this namespace "detail", because then we'd
have both ::mozilla::detail and ::mozilla::dom::detail namespaces in
the tree and various template name lookups that look for "detail::Foo"
would get confused, and the code would not compile.  C++ strikes
again.
Attachment #8358476 - Flags: review?(peterv)
We can avoid the include of BindingUtils.h in UnionTypes.h if we move FakeDependentString to a separate header... which we may well want to do, in fact.  Let me know?
Attachment #8358480 - Flags: review?(peterv)
Whiteboard: [need review]
Attachment #8358476 - Flags: review?(peterv) → review+
Comment on attachment 8358480 [details] [diff] [review]
part 2.  Move FakeDependentString to the binding_detail namespace.

Review of attachment 8358480 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bindings/Codegen.py
@@ +3646,5 @@
> +            conversionCode = ("%s\n"
> +                              "${declName} = &${holderName};" %
> +                              getConversionCode("${holderName}"))
> +        else:
> +            declType = "binding_detail::FakeDependentString"

Do we want to specialize NonNullHelper for FakeDependentString so that it returns a nsAString?
Attachment #8358480 - Flags: review?(peterv) → review+
> Do we want to specialize NonNullHelper for FakeDependentString

I tried to, but I get the compiler complaining that my specialization doesn't match any of the function templates.  :(
Backed this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/ee997698be4a (along with the patch from bug 962605) because one of them seems to have introduced a new permanent failure only on OSX 10.8 m-oth: 
https://tbpl.mozilla.org/php/getParsedLog.php?id=33415277&tree=Mozilla-Inbound
Whiteboard: [qa-]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: