Incorrect binding to modes by name
Test override-v-015 demonstrates a problem with the binding of modes by name.
The initial mode is found by searching all mode components to find the first with a matching name. This is incorrect: it should always find a mode in the top-level package. Fixed this by using the same logic for finding the initial mode as we currently use for the initial function and the initial template.
This demonstrates another issue (which may be symptom-free): the index of modes (by name) held in context.fixed.modes is wrong in principle, because there can be several modes (in different packages) with the same name.
The same is true of the other indexes in context.fixed, such as context.fixed.globalVars and context.fixed.userFunctions.
Updated by Michael Kay over 6 years ago
- Status changed from New to In Progress
- Applies to JS Branch 0.9, 1.0, Trunk added
- Fix Committed on JS Branch Trunk added
I have fixed the original issue with override-v-015 by changing the way the initial mode is found.
I have eliminated context.fixed.modes.
I have eliminated context.fixed.globalVars.
Changes committed on the 2.0 branch.
Leaving open: need to discuss with John if there are any complications in eliminating context.fixed.userFunctions.
Updated by John Lumley over 6 years ago
At present I don't think the
xsl:evaluate code uses
context.fixed.userFunctions in the compiliation phase - signatures are determined by searching a mapping of
name->component, in three distinct categories: "@function@", "@globalVariable@" and "@globalParam@" that has been generated from
context.fixed.components. This suggests that
context-fixed.userFunctions might be redundant for compilation and evaluation, since
ufCall at runtime also searches for components. I'll check this tomorrow. I haven't yet checked this in a situation where there are multiple packages.
There are a very few points in the XPath code that reference
context.fixed.globalVars but I think they are now redundant - will check.
Please register to edit this issue