DOMProxyHandler::delete_ looks like this in my tree: > bool > DOMProxyHandler::delete_(JSContext* cx, JS::Handle<JSObject*> proxy, JS::Handle<jsid> id, bool* bp) const > { > MOZ_ASSERT(!xpc::WrapperFactory::IsXrayWrapper(proxy), > "Should not have a XrayWrapper here"); > > int32_t index = GetArrayIndexFromId(cx, id); > if (IsArrayIndex(index)) { > bool result; > bool found = false; > mozilla::dom::TestIndexedDeleterWithRetvalInterface* self = UnwrapProxy(proxy); > self->IndexedDeleter(index, found); > MOZ_ASSERT(!JS_IsExceptionPending(cx)); > if (found) { > *bp = result; > } else { > *bp = true; > } > // We always return here, even if the property was not found > return true; > } > > return dom::DOMProxyHandler::delete_(cx, proxy, id, bp); > } cppcheck says that |result| is used without being initialized. It is correct, AFAICT.

This is in $OBJDIR/dom/bindings/TestCodeGenBinding.cpp, BTW.

Yeah, ok. So the good news is that there are no indexed deleters in any non-test code, and I hope there never will be. Is it viable to just drop support for them instead of trying to fix this code to be sane?

Yes I think we should drop support for indexed deleters. I am reminded by looking at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20535 that we do have a use of indexed creators. :( But deleters can go as far as I know.

If not, then the point is that we should be assigning the return value of IndexedDeleter to "result" in this case. The TestNamedDeleterWithRetvalInterface case has a similar issue... Again, luckily our extant named deleters all return void.

CGCallGenerator is only assigning stuff to resultVar if needResultDecl. That's wrong.

Removed from the spec: https://github.com/heycam/webidl/commit/291dcc397f48029ac3954b2b0e511f4c14c7631d