"partial" regexps (<#FOO>) cause false-positive warnings
dweiss opened this issue · comments
Thank you for the plugin. It is helpful. I just wanted to point out that currently "partial" regexp definitions cause warnings. Something like:
<DEFAULT> TOKEN : {
<#_NUM_CHAR: ["0"-"9"] >
// Every character that follows a backslash is considered as an escaped character
| <#_ESCAPED_CHAR: "\\" ~[] >
| <#_TERM_START_CHAR: ( ~[ " ", "\t", "\n", "\r", "\u3000", "+", "-", "!", "(", ")", ":", "^", "@",
| <PLUS: "+" >
...
would bring a warning like this:
"+" cannot be matched as the string literal token <PLUS>, _TERM_CHAR matches its input instead
This isn't true because pound-starting definitions don't generate tokens of their own - they're just expanded into final tokens, if used.
Thanks for the report, I'll try to find time for this shortly
No worries. Thank you!
So I've been looking into this bug and am having trouble reproducing it... The example you provide has a syntax error, and even if corrected, I don't see an issue (even when adding tokens like your _TERM_CHAR). Could you provide a minimal working example?
This is a smaller example that reproduces the problem.
PARSER_BEGIN(Example)
public class Example {
}
PARSER_END(Example)
<DEFAULT> TOKEN : {
<#_FRAGMENT: ["0"-"9"] >
| <QUOTED: "\"" ( <_FRAGMENT> )* "\"">
| <ZERO: "0" >
}
public Void Rule() :
{
}
{
<QUOTED> | <ZERO>
{
return null;
}
}
Note how QUOTED uses the fragment to define a regexp that contains it. The fragment will never match on its own but the plugin claims a conflict with token ZERO.
Misclick
Thanks, I'll look into this tomorrow
I was able to reproduce the bug, it should be fixed in version 1.7, which I'll release sometime this week. Thanks for your cooperation Dawid !