parse error "can't look backwards more than one token in this stream"

[abons]

var user = userservice"getuser"; --doesn't work
var user = userservice.getuser(); --works

The above 2 lines are both fine syntax. But the first line gives the parse error "can't look backwards more than one token in this stream". I can't use the 2nd line, because I use a variable within the brackets.

Is it possible to add my own excludeRule?
For instance with a regular expression .*

[ryaneberly]

Exclude rules are supported.
The simplest being adding one to etc/cflintexcludes.json. It's not well
documented, and I don't think it currently supports regex -- which is a
good idea.

When I tried it just now, I got multiple errors in the result html for a
single parsing problem.

I'll look at these tonight. If you are familiar with Java and feeling
adventurous, see:
com.cflint.tools.CFLintFilter for how cflintexcludes.json is used
and
com.cflint.TestCFBugs_ParseError.testSimpleCFSET() for an example of
testing how the parsing errors act.

Thanks for the input.

On Wed, Dec 3, 2014 at 5:24 AM, Axel Bons notifications@github.com wrote:

var user = userservice"getuser"; --doesn't work
var user = userservice.getuser(); --works

The above 2 lines are both fine syntax. But the first line gives the parse
error "can't look backwards more than one token in this stream". I can't
use the 2nd line, because I use a variable within the brackets.

Is it possible to add my own excludeRule?
For instance with a regular expression .*

—
Reply to this email directly or view it on GitHub
#24.

[ryaneberly]

I enhanced CFLintFilter to support excludes by 'expression'. That won't be available for download until we do a new release, but you can build it yourself.

You can currently do excludes based on:
file - (file name with the violation)
code - (such as PARSE_ERROR)
function - function name
variable -
line - line of code (as reported by CFLint, usually the same as the real source code line)

All these variables already support regex (of the java String.matches() variety)

So I suggest using the current release and adding something like, to ignore PARSE_ERROR on specific file.:
,{file="myfile.cfc",code="PARSE_ERROR"}
or, ignore PARSE_ERROR on specfic line in specific file
,{file="myfile.cfc",code="PARSE_ERROR",line="43"}
or, with the latest code to ignore all PARSE_ERRORs on source containing "getuser"
,{expression="."getuser".",code="PARSE_ERROR"}

to /etc/cflintexclude.json

you'll see there's already a pretty broad rule in there by default that ignores violations in the init() function. We should probably narrow that a bit to just VAR missing violations.

[abons]

The excluderule which worked for me was:
,{"code":"FILE_ERROR","File":"C:\objectSelection.cfc"}

With the excluderule the warning won't be in the results.
But any problems occuring after the line which resulted in the file error won't be parsed.
For example the following code in cfscript:

var user = userservice"getuser";
anotherVar = 1;

The missing_var warning for the 2nd line won't be in the results.

[ryaneberly]

jjames967 has been looking at enhancing the CF parser that we're using - that is a significant task. We use the same parser that is used by CFEclipse, and it has quite a few issues that could be improved upon.

Ideally we'd just fix this parsing error.

However, there are a some work-arounds. cfscript gets consumed all at once. If your cfc is not pure cfscript, and your code is inside a tag, you can break the cfscript into pieces.

....

<cfset var user = userservice"getuser"/>

anotherVar = 1;

However, I dislike when the limitations of a tool influence coding like that.

I agree it would be nice if the parser just failed on a single line and consumed the the remaining ones successfully. I'll think about that, maybe it's doable even within the current parser's limitations.

[ryaneberly]

fixed in antlr4 branch.. hopefully releasing soon.