I used find and replace to finish the job. All this PR does is replace
all `Error::<error_name>` occurrences with `Error::<error_name>(None)`.
Testing: Refactor
Fixes: #39053
Signed-off-by: Ashwin Naren <arihant2math@gmail.com>
The result of a predicate can depend on the position of the node in its
set, and this position is dependent on the axis that the node set came
from. This is specified in
https://www.w3.org/TR/1999/REC-xpath-19991116/#predicates.
Additionally, this change fixes a small bug in the implementation of
`preceding::` (https://github.com/servo/servo/pull/40588) where the root
of a subtree would be included twice. That wasn't discovered earlier
because nodes are deduplicated at the end of the evaluation.
Testing: New tests start to pass, this change adds more tests
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
`preceding::` needs to yield all preceding nodes, excluding ancestors.
`following::` needs to yield all following nodes, excluding descendants.
Both `Node::preceding_nodes` and `Node::following_nodes` (which we're
currently using) don't quite match these requirements, so we have to
engineer some xpath-specific iterators.
Testing: New tests start to pass
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
This change adds `NodeSet`, which is more or less a `Vec<Node>` that
knows whether it is sorted, and can sort itself if it isn't. This allows
us to efficiently enforce tree order in intermediary node sets that
occur during evaluation.
Notably, in many cases it is not necessary to sort at all, because all
location step expressions yield node sets that are either already sorted
(`Axis::DescendantOrSelf` for example), or that are in inverse tree
order (`Axis::PrecedingSiblings` for example).
There's still optimization work left to be done. When merging two node
sets that are already sorted then we could use merge sort instead of
appending one to the other and naively sorting. But I suspect that the
sorting algorithm used by the standard library is already well tuned to
handle such cases...
Testing: This change adds a web platform test
Fixes https://github.com/servo/servo/issues/40435
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
I always thought that exceptions thrown in namespace resolver callbacks
should be propagated to the call site of `document.evaluate`.
That is not the case - the exception is silently swallowed and you get a
namespace error, the same as if the callback had returned any other
invalid value.
Testing: New web platform tests start to pass
Fixes https://github.com/servo/servo/issues/39931
Part of #34527
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
This change was split of from https://github.com/servo/servo/pull/39977
to make that PR easier to review.
The `Debug` impl for the error is not very useful yet, but
https://github.com/servo/servo/pull/39977 swaps out the error type
itself, so there's no point in improving it here.
Testing: I've manually tested that the error message appears. I don't
think we have tests for error messages.
Part of #34527
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
We don't need to care about namespace prefixes in name tests because
they are already resolved to namespaces at this point.
The old implementation was also masking a few other small bugs which
I've fixed here. When the namespace resolver doesn't give us any results
then we should not lookup the namespace on the node itself. In XPath,
namespaces on html elements in html documents are compared a in a
relaxed way, and we were previously also using the relaxed comparison
mode on non-html elements in html documents (like svg).
Testing: Existing tests continue to pass (and the web platform tests
contain numerous namespace tests which cover this behaviour)
Fixes https://github.com/servo/servo/issues/39939
Part of #34527
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
XPath (and, in the future, XSLT) is only loosely coupled to `script`. As
`script` is already very large, I'd like to move the xpath parser and
evaluator into a seperate crate. Doing so allows us to iterate on it
more easily, without having to recompile `script`. Abstracting over the
concrete DOM implementation could also allow us to write some more
comprehensive unit tests.
Testing: Covered by existing web platform tests
Part of https://github.com/servo/servo/issues/34527
Fixes https://github.com/servo/servo/issues/39551
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
