Makopo / lslint

lslint is a tool to check the syntactic and semantic validity of Second Life LSL scripts.
http://w-hat.com/lslint
32 stars 15 forks source link

Ignore "inline" LSL-PyOptimizer directive #94

Closed Makopo closed 4 years ago

Makopo commented 5 years ago

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.

Makopo commented 5 years ago

FYI, lslint -i test.lsl only removes the first error.

Sei-Lisa commented 5 years ago

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.

Sei-Lisa commented 5 years ago

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.

Makopo commented 5 years ago

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.

Sei-Lisa commented 5 years ago

Thanks, but are you sure the regexp is OK? That looks very much like the lslint one.

Makopo commented 5 years ago

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.

Makopo commented 5 years ago

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

Sei-Lisa commented 5 years ago

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

Makopo commented 5 years ago

Thank you for enhancement. It seems work so I revised README.

Sei-Lisa commented 4 years ago

Can this issue be closed?

Makopo commented 4 years ago

Yes. Thanks.