On 08/18/2016 12:21 AM, Santiago Vila wrote:
> xsltc.java_cup:
> [echo] java_cup preparsing
> [java] Exception in thread "main" java.lang.Error: Error: could not
> match input
> [java] at java_cup.Lexer.zzScanError(Lexer.java:728)
> [java] at java_cup.Lexer.next_token(Lexer.java:1058)
> [java] at java_cup.parser.scan(parser.java:417)
> [java] at java_cup.runtime.lr_parser.parse(lr_parser.java:578)
> [java] at java_cup.Main.parse_grammar_spec(Main.java:477)
> [java] at java_cup.Main.main(Main.java:186)
> [java] at
> org.apache.xalan.xsltc.util.JavaCupRedirect.main(JavaCupRedirect.java:90)
Thank you for the report Santiago, the package also fails to build
without the -A flag btw.
This error happens when cup processes
src/org/apache/xalan/xsltc/compiler/xpath.cup.
It started with the upload of cup 0.11a+20060608-7 required by the
upgrade of jflex to the version 1.6.1. xpath.cup has DOS line endings
(\r\n), converting the file to the Unix format solves the issue.
Looking at the changelog for the recent versions of jflex [1] one thing
caught my attention, in jflex 1.5.0 there was:
The . meta character now stands for all non-newline characters.
The meaning of the dot (“.”) meta character has been changed
from [^\n] to [^\n\r\u000B\u000C\u0085\u2028\u2029].
Use the new --legacydot option to cause “.” to be interpreted
as [^\n]
In cup the flex/Lexer.jflex file has a rule like this [2] :
.|\n { sb.append(yytext()); }
With the old definition of the dot this matched any character, but with
the new definition it misses \r\u000B\u000C\u0085\u2028\u2029. This
probably explains why converting the cup file to the Unix format solved
the issue.
I modified the cup package to enable the legacydot option during the
build and it solved the libxalan2-java FTBFS. I plan to upload the
fixed cup package soon.
Emmanuel Bourg
[1] http://jflex.de/changelog.html
[2] https://sources.debian.net/src/cup/0.11a%2B20060608-7/flex/Lexer.jflex/#L103
