Getting rid of SetterMayThrowException might be possible by inspecting the DOM class setter prototype.
Created attachment 321122 [details] WIP
Comment on attachment 321122 [details] WIP Attachment 321122 [details] did not pass bindings-ews (mac): Output: http://webkit-queues.webkit.org/results/4586150 New failing tests: (JS) JSTestCallTracer.cpp (JS) JSTestCEReactions.cpp (JS) JSTestCEReactionsStringifier.cpp (JS) JSTestEnabledBySetting.cpp (JS) JSTestGlobalObject.cpp (JS) JSTestInterface.cpp (JS) JSTestNode.cpp (JS) JSTestObj.cpp (JS) JSTestSerialization.cpp (JS) JSTestSerializationInherit.cpp (JS) JSTestSerializationInheritFinal.cpp (JS) JSTestSerializedScriptValueInterface.cpp (JS) JSTestStringifierReadWriteAttribute.cpp (JS) JSTestTypedefs.cpp
Sam, Chris, any feedback on that patch before I finalize it? This patch allows removing SetterMayThrowException and SetterCallWith from the binding generator. A follow-up patch would clean the IDLs, remove GetterMayThrowException and probably CallWith from any attribute declaration. The downside of the patch approach is that it reduces the flexibility on how to write setters. As can be seen in the patch, the removed flexibility is not huge.
If landing such patch, we should make sure there is no related perf regression.
Rather than overloading like this, could instead do something like (I have not compiled this, this is a sketch): template<bool canThrowException> struct CallSetter; template<> struct CallSetter<true> { template<typename Functor> static void call(JSC::ExecState& state, JSC::ThrowScope& throwScope, Functor functor) { propagateException(state, throwScope, functor()); } }; template<> struct CallSetter<false> { template<typename Functor> static void convert(JSC::ExecState&, JSC::ThrowScope&, Functor functor) { functor(); } }; --- CallSetter<WTF::IsTemplate<decltype(impl.setValues(WTFMove(nativeValue))), ExceptionOr>::value>::call(state, throwScope, [&] { return impl.setValue(WTFMove(nativeValue)); });
It is probably working and this would be probably applicable to methods as well. It would not get rid of CallWith though. Might be a good tradeoff.
Created attachment 321151 [details] Proof of concept that works Working proof of concept.
(In reply to Sam Weinig from comment #8) > Created attachment 321151 [details] > Proof of concept that works > > Working proof of concept. Do you want to take over this one? Otherwise, I will finalize the patch with your proposal.
(In reply to youenn fablet from comment #9) > (In reply to Sam Weinig from comment #8) > > Created attachment 321151 [details] > > Proof of concept that works > > > > Working proof of concept. > > Do you want to take over this one? > Otherwise, I will finalize the patch with your proposal. You should do it.
Created attachment 321457 [details] Patch
Comment on attachment 321457 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=321457&action=review > Source/WebCore/ChangeLog:56 > + * bindings/scripts/test/JS/JSTestObj.cpp: > + (WebCore::setJSTestObjConstructorStaticStringAttrSetter): > + (WebCore::setJSTestObjEnumAttrSetter): > + (WebCore::setJSTestObjByteAttrSetter): > + (WebCore::setJSTestObjOctetAttrSetter): > + (WebCore::setJSTestObjShortAttrSetter): > + (WebCore::setJSTestObjClampedShortAttrSetter): I think you can remove some of these function names that changed in test result lines. > Source/WebCore/bindings/js/JSDOMAttribute.h:111 > + static void call(JSC::ExecState&, JSC::ThrowScope&, Functor&& functor) { functor(); } This should use the normal syntax, braces on their own lines.
(In reply to Sam Weinig from comment #12) > Comment on attachment 321457 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=321457&action=review > > > Source/WebCore/ChangeLog:56 > > + * bindings/scripts/test/JS/JSTestObj.cpp: > > + (WebCore::setJSTestObjConstructorStaticStringAttrSetter): > > + (WebCore::setJSTestObjEnumAttrSetter): > > + (WebCore::setJSTestObjByteAttrSetter): > > + (WebCore::setJSTestObjOctetAttrSetter): > > + (WebCore::setJSTestObjShortAttrSetter): > > + (WebCore::setJSTestObjClampedShortAttrSetter): > > I think you can remove some of these function names that changed in test > result lines. > > > Source/WebCore/bindings/js/JSDOMAttribute.h:111 > > + static void call(JSC::ExecState&, JSC::ThrowScope&, Functor&& functor) { functor(); } > > This should use the normal syntax, braces on their own lines. Mind if I do the others?
(In reply to Sam Weinig from comment #13) > (In reply to Sam Weinig from comment #12) > > Comment on attachment 321457 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=321457&action=review > > > > > Source/WebCore/ChangeLog:56 > > > + * bindings/scripts/test/JS/JSTestObj.cpp: > > > + (WebCore::setJSTestObjConstructorStaticStringAttrSetter): > > > + (WebCore::setJSTestObjEnumAttrSetter): > > > + (WebCore::setJSTestObjByteAttrSetter): > > > + (WebCore::setJSTestObjOctetAttrSetter): > > > + (WebCore::setJSTestObjShortAttrSetter): > > > + (WebCore::setJSTestObjClampedShortAttrSetter): > > > > I think you can remove some of these function names that changed in test > > result lines. OK > > > Source/WebCore/bindings/js/JSDOMAttribute.h:111 > > > + static void call(JSC::ExecState&, JSC::ThrowScope&, Functor&& functor) { functor(); } > > > > This should use the normal syntax, braces on their own lines. I like one-line getters/setters and it does seem very close to that. But I don't have a strong opinion. > Mind if I do the others? Meaning to apply this for getters and operations? Sure! I'll land this one and will update all IDLs using SetterRaisesException in a follow-up.
Created attachment 321489 [details] Patch for landing
Comment on attachment 321489 [details] Patch for landing Clearing flags on attachment: 321489 Committed r222365: <http://trac.webkit.org/changeset/222365>
All reviewed patches have been landed. Closing bug.
<rdar://problem/34694289>