Ignore "inline" LSL-PyOptimizer directive
Closed this issue · 11 comments
lslint doesn't ignore "inline" directive used for @Sei-Lisa's LSL-PyOptimizer.
For example, this code throws following errors.
test.lsl::ERROR:: ( 1, 9): syntax error, unexpected IDENTIFIER, expecting '('
test.lsl::ERROR:: ( 17, 5): syntax error, unexpected '{'
test.lsl::ERROR:: ( 19, 20): syntax error, unexpected STRING_CONSTANT
test.lsl::ERROR:: ( 28, 22): syntax error, unexpected ';', expecting '{'
test.lsl::ERROR:: ( 31, 19): syntax error, unexpected '('
test.lsl::ERROR:: ( 53, 12): syntax error, unexpected INTEGER_CONSTANT
TOTAL:: Errors: 6 Warnings: 0
[Finished in 0.3s with exit code 6]
I posted this issue inspired by inworld inquiry from Cindy Reynaud.
FYI, lslint -i test.lsl
only removes the first error.
PyOptimizer has a number of syntax extensions, not just this one. Adding support for them all is quite a bit of work. Cindy may want inline keywords, other users may want expressions in globals, others may want C-style string juxtaposition, others may want multiple labels with the same name, and so on.
I wonder if lslint needs to support all these syntax extensions. An alternative solution is that the ST plugin that Cindy is using could support PyOptimizer instead of lslint. She's using https://github.com/Makopo/sublime-text-lsl - how easy or hard would it be to allow the user to enter the full path to the executable, and to adapt it to the syntax it outputs? In this case there are two paths to enter, first the path to Python and then the path to the optimizer, but they could be in the same setting.
There's also https://github.com/riej/lsl_ext which offers a number of other syntax extensions. Other users may want to use these with their editor. Supporting them all is a lot of work, and lslint was not designed for that. A few syntax extensions like lazy lists and switch statements are widely supported due to being incorporated into Firestorm and the optimizer, but I don't think we should go beyond that.
For this reason, I think the best way to handle this is to add support for the desired tool in the editor. And if the editor is ST, then sublime-text-lsl is the one that should add support for other tools.
What @Sei-Lisa says makes sense to me so I added the instruction to change build tool from lslint to LSL-PyOptimizer to README.md. I haven't supported any dialects on the ST plugin so this would be a reasonable solution.
Thanks, but are you sure the regexp is OK? That looks very much like the lslint one.
I keep it as the same as lslint for the time being, since it anyway actually won't work now. ST build system file_regex needs filename on each line. (line_regex doesn't require it but anyway filename should be at somewhere) FYI that's why I forked original lslint and added -p
option for ST plugin.
For LSL-PyOptimizer, ^()\\(Line\\s*([0-9]+)\\s*char\\s*([0-9]+)\\):\\s(.*)
will come closer to success, if the first group contains the filename. FYI, ST regex is perl based.
(?=^.*?in\\s\"(.*?)\":)^\\(Line\\s([0-9]+)\\schar\\s([0-9]+)\\).*:\\s(.*?)$
would work if the line looks like (Line 10 char 17): ERROR in "somefile.lsl": Name not defined within scope
Thanks so much for the information. I've pushed a change that introduces a flag, --emap
, that outputs EMAPs (Error Messages suitable for Automated Processing). Unless I made a mistake, it can be captured with this regex:
"file_regex": "^::[A-Z]++::\"((?:\\\\.|[^\"\\\\])*+)\":(\\d++):(\\d++): (.*+)"
Sorry for the extended off-topic. This actually belongs in the sublime-text-lsl project
Thank you for enhancement. It seems work so I revised README.
Can this issue be closed?
Yes. Thanks.