Highlighting errors in XSLT
The XSLT support can detect a range of errors in XSLT constructs, such as misspelled template names, missing template parameters, bad match-patterns, references to undeclared variables, wrong or useless embedded XPath expressions, and so on and also offers quick-fixes to automatically fix some of those errors.
Install and enable the XPathView + XSLT plugin on the Settings | Plugins page, tab Marketplace, as described in Installing plugins from JetBrains Marketplace.
Where allowed, XPath function-calls, Axis names, Numbers, Strings, and so on are highlighted according to the currently active color scheme. If a different coloring is desired, those colors can be configured in the tab on the Color Scheme page of the .
Just like the interactive XPath Expression Evaluation, the XSLT support catches any syntax error in XPath expressions used inside a Style Sheet.
In XPath, almost all types are assignable to each other with certain well-defined conversion semantics. However, the conversion to NODESET isn't defined for any type, and there's also no (portable) conversion function available. Such type-conversions are highlighted as an error.
A special form of XPath expression are patterns in XSLT. For example, they are used as the value of the match-attribute in xsl:template elements. Only a certain subset of XPath expressions is allowed here, which the XSLT support checks for.
References to variables that have not been declared or are not accessible from the current scope are detected and highlighted as an error. There are quick-fixes available to create a variable or parameter declaration for such unresolved variables references.
Quick-fixes:
In XSLT there must not be more than one variable or parameter declared on the same scope level. It's also not allowed that there is more than one template with the same name. The plugin will identify such duplicate declarations and highlight them in the editor.
Even though it is possible to have identically named variables or parameters in different nesting levels, this can be confusing and is likely to cause programming mistakes. The plugin can identify shadowed declarations and offers quick-fixes to either rename the local or the outer variable.
Another check that the XSLT support performs is whether all required parameters are specified with a xsl:call-template. A parameter is considered required if there is no default value, that is if there's no select attribute and the parameter's declaring element has an empty body.
Quick-fixes:
There's also a supplemental check that flags arguments that are not declared as template parameters. There are Quick-fixes available to either remove the argument from the template-call or to add a corresponding parameter to the called template.
Quick-fixes:
The XSLT support does, just like the interactive XPath Expression Evaluation, check whether the number and types of function arguments match their declaration for built-in functions of XPath and XSLT.
All XPath inspections are supported for editing XSLT documents. Those inspections can also be suppressed in a way that is similar to the standard suppression-mechanism CLion uses for Java code by using noinspection XML comments. The suppression is possible on different levels, either on instruction level, template-level (if applicable) or Style Sheet level.
Thanks for your feedback!