# Saxon 7.8 reports a very misleading line number when the
# error is generated at the interface of a lazily evaluated function.
Thanks: yes, I know. But it's not obvious what to do about it. The cleverer
the optimizer gets, the harder it is to relate run-time errors back to the
source code. One possibility is a switch to suppress optimization. Another
is to push line number information further down into the compiled XPath code
- at the moment it's always generated at the XSLT instruction level.