Merged
Conversation
No longer is "No stylesheet found" the top error message! Curiously, all tests using environment-defined stylesheet also use another unsupported XSLT feature, meaning we gain a net total of 0 newly-working tests. Pity!
1. When getting an Unexpected error from the second part of an OrParser, surface the original error from the first part as it's more likely to be useful for debugging. (In theory, we need an aggregated error listing both parts to fully capture the error) 2. When getting an Unexpected error from parsing the XSLT, print out the offending piece of XSLT code
faassen
approved these changes
Jan 5, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After my work in #124, I was about to head back to xsl:param-s, when I noticed that the top error was actually "No stylesheet found" and not something about params. Upon investigation, I found that this was due to missing support for stylesheets defined in the environment in the test runner.
Sadly, this did not lead to any new tests getting magically solved, because virtually all test cases using environment stylesheets use params to control the behavior of the repeated stylesheet.
At that point, the output of the error-sorting pipeline from #124 (
cargo run --release --bin xee-testrunner -- -v all vendor/xslt-tests/ | cut -sd' ' -f3- | cut -d'(' -f-2 | sort | uniq -c | sort -h), looked like the following:...Which led to me investigating what causes
<xsl:template>parsing to fail. It turned out to be an issue with error reporting in theOrParser, where a<xsl:template>match failing due to unsupported XSLT features then got retried as a<xsl:stylesheet>match, which failed with an unhelpful error pointing at the root element. In the second commit, I touched up theOrParserso it would return the error from the first match in case the second match error is "Unexpected".And now, the output of the error-sorting pipeline finally looks like this:
Now clearly,
xsl:paramdeclarations are the XSLT feature that causes the most tests to fail. 😂