Created attachment 53051 [details]
The stylesheet

Created attachment 53052 [details]
The source file

Created attachment 55202 [details]
Stripped down stylesheet

Created attachment 55203 [details]
Stripped down source file

Maybe I forgot to mention that xsltproc worked on these same stylesheets before
1.1.15.

Here's the output -v gets on the minimal files:

creating dictionary for stylesheet
reusing dictionary from libxslt-faulty-xpath.xsl for stylesheet
Added namespace: xsl mapped to http://www.w3.org/1999/XSL/Transform
xsltParseStylesheetProcess : found stylesheet
xsltPrecomputeStylesheet: removing ignorable blank node
Registering global variable a
Defining global variable a
xsltCompilePattern : parsing 'foo[. = $a]'
XPath error : Undefined variable
compilation error: file libxslt-faulty-xpath.xsl line 7 element template
Failed to compile predicate
xsltCompilePattern : parsed foo[. = $a], default priority 0.500000
added pattern : 'foo[. = $a]' priority 0.500000
parsed 1 templates
freeing dictionary from stylesheet

<xsl:template match="foo[. = $a]">

It's forbidden to reference variables in a match pattern.
Libxslt used to not check this, it rightly raise an error now.

  Not a bug,

Daniel

Hi Daniel,

can you please explain, why you think that's forbidden to reference a variable from a match pattern? From the pattern rule

  http://www.w3.org/TR/xslt#NT-Pattern

it's easy to derive the pattern "foo[. = $a]" of this example, as can be seen below. I can't find any hint in the spec that otherwise forbids variable references in patterns. And, by the way, the current Xalan transformer (2.7.0) does things "right" with vars in pattern. 

Of cause, only globally defined vars and params are visible for the match, but those are, as the spec explicitly says in "11.4 Top-level Variables and Parameters": "A top-level variable-binding element declares a global variable that is visible everywhere."


Derivation of the "problematic" pattern:

Pattern
LocationPathPattern
RelativePathPattern
StepPattern
ChildOrAttributeAxisSpecifier NodeTest Predicate*
'child::foo' Predicate
'child::foo[' PredicateExpr ']'
'child::foo[' Expr ']'
'child::foo[' Expr ']'
'child::foo[' OrExpr ']'
'child::foo[' AndExpr ']'
'child::foo[' EqualityExpr ']'
'child::foo[' EqualityExpr '=' RelationalExpr ']'
'child::foo[' RelationalExpr '=' RelationalExpr ']'
'child::foo[' AdditiveExpr '=' AdditiveExpr ']'
'child::foo[' MultiplicativeExpr '=' MultiplicativeExpr ']'
'child::foo[' UnaryExpr '=' UnaryExpr ']'
'child::foo[' UnionExpr '=' UnionExpr ']'
'child::foo[' PathExpr '=' PathExpr ']'
'child::foo[' PathExpr '=' PathExpr ']'
'child::foo[' LocationPath '=' FilterExpr ']'
'child::foo[' RelativeLocationPath '=' VariableReference ']'
'child::foo[' Step '=' VariableReference ']'
...
'child::foo[ . = $a ]'

Reference XSLT spec 5.3 [Defining Template Rules]
"A template rule is specified with the xsl:template element. The match
attribute is a Pattern that identifies the source node or nodes to which the
rule applies. The match attribute is required unless the xsl:template element
has a name attribute (see [6 Named Templates]). It is an error for the value of
the match attribute to contain a VariableReference. "

Also see http://bugzilla.gnome.org/show_bug.cgi?id=441115

Thank's for the clarification. This side note is hard to find - I even would opt against implementing it... :-)

Bernhard