Add [TypeChecking=Interface] to XPath interfaces

Source/core/xml/XPathExpression.idl

Index: Source/core/xml/XPathExpression.idl
diff --git a/Source/core/xml/XPathExpression.idl b/Source/core/xml/XPathExpression.idl
index 35ab9089439e80a55903c2acd40de36e6b5438a3..de87b4e32d349556765fc6630dfe67dba73ac6ba 100644
--- a/Source/core/xml/XPathExpression.idl
+++ b/Source/core/xml/XPathExpression.idl
@@ -19,10 +19,8 @@
  */
 
 [
-    WillBeGarbageCollected
+    WillBeGarbageCollected,
+    TypeChecking=Interface,
 ] interface XPathExpression {
-     [RaisesException] XPathResult evaluate([Default=Undefined] optional Node contextNode,
-                                        [Default=Undefined] optional unsigned short type,
-                                        [Default=Undefined] optional XPathResult inResult);
+     [RaisesException] XPathResult evaluate(Node contextNode, optional unsigned short type = 0, optional object? inResult = null);

[philipj_slow, 2015/03/09 08:17:30]

I now see that inResult is not actually used, the previous code was odd indeed,
un-obviously ending up unused in XPathExpression::evaluate. If the only effect
it can have it to throw if type checking fails, and that was previously a silent
error, how about just removing the argument everywhere?

[Jens Widell, 2015/03/09 08:30:22]

Firefox throws if the argument value is not an object (or null/undefined). I was
sort of aiming for the same, but we actually (incorrectly) treat 'object' and
'any' the same in the code generator, so there's effectively no difference to
not having the argument at all.

That we don't use it is an implementation detail. Using it was always optional
in the specification. I'm not sure it's an overall win to omit the argument in
the IDL, given that a hypothetical specification would probably have it.

[philipj_slow, 2015/03/09 10:10:47]

OK, http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator-evaluate
says:

"The result specifies a specific result object which may be reused and returned
by this method. If this is specified as null or the implementation does not
reuse the specified result, a new result object will be constructed and
returned."

Very strange. If I were writing a new spec for this I'd certainly remove the
argument unless required for compat (unlikely) but OK to leave it alone until
there is a spec.

[Jens Widell, 2015/03/09 11:05:10]

Presto actually reused the result object, if one was provided.

But sure, it would be reasonable to drop the argument if a modern specification
was written, and most likely safe from a compatibility point of view; it hardly
makes sense to write a script that *assumes* the result object is reused. And
either way, it wouldn't affect Blink's compatibility, since we already don't
reuse it.

 };
-