The latest mvn verify run for GawkCompatibilityIT shows a large compatibility gap around gawk's @-prefixed syntax.
Observed impact:
- 29 failing Gawk compatibility cases in the latest run
- Representative cases: include,
sbad,
sbad2,
sforloop,
sfuncrecurse,
sindirect1, indirectbuiltin, indirectcall2, indirectcall3, typedregex2, typedregex3, typedregex5, typedregex6, typeof1, typeof3, regexsub, functab4, functab5, ordchr, time
- Current failure mode is mostly LexerException: Invalid character (64): @
This points to missing frontend support for the core gawk @ forms used by the suite, including:
@include@namespace- indirect function or builtin calls such as
@f(...)
- strongly typed regexp literals such as
@/.../
Acceptance criteria:
- Jawk no longer rejects
@ at lexing time for the supported gawk forms
- the representative compatibility cases above compile and execute through the IT harness
- unsupported
@ forms, if any remain, fail with a specific and intentional diagnostic instead of a generic lexer error
Note: @ syntax is not POSIX compliant and therefore should be disabled is POSIX mode is requested in AwkRunBuilder. This is an option for AwkParser.
The latest mvn verify run for GawkCompatibilityIT shows a large compatibility gap around gawk's @-prefixed syntax.
Observed impact:
sbad,
sbad2,
sforloop,
sfuncrecurse,
sindirect1, indirectbuiltin, indirectcall2, indirectcall3, typedregex2, typedregex3, typedregex5, typedregex6, typeof1, typeof3, regexsub, functab4, functab5, ordchr, time
This points to missing frontend support for the core gawk @ forms used by the suite, including:
@include@namespace@f(...)@/.../Acceptance criteria:
@at lexing time for the supported gawk forms@forms, if any remain, fail with a specific and intentional diagnostic instead of a generic lexer errorNote:
@syntax is not POSIX compliant and therefore should be disabled is POSIX mode is requested in AwkRunBuilder. This is an option for AwkParser.