cli: Add lint subcommand

[neptuwunium]

Essentially only calls the AST parser on a pattern file.

This is particularly useful for people wishing to integrate pattern error checking into an existing editor (like Visual Studio Code, which I am planning to (attempt) to create.)

The alternative would be a full blown language server which is significantly more work.

[paxcut]

Did you know that the patter editor already does this and more? It parses the pattern as you type it and if errors are found it puts markers on the error location and hovering over the markers gives you the full error description.

In addition, the semantic highlights give you error checking by setting the color of identifiers it can't classify as one of the 14 different types of variables that exist in pattern language (like global variables , local variables, function parameters, ...) with the color selected for unknown identifiers. It will catch typos, improper member selection, invalid parent members, and any other condition that makes the semantic highlighter fail to classify the identifier.

It uses the parser to obtain information about definitions and declarations and uses them to parse the pattern semantically. You can't get that kind of static analysis from an external editor without a language server. Furthermore the pattern debugger is fully integrated with the editor for the ultimate debugging experience.

I understand some prefer to use their own editor despite all that. You probably already know this but I'll mention it just in case. You can open the pattern in the pattern editor and in your own editor at the same time and they will synchronize if you set your editor to track the file on disk.

The following is just a suggestion that you may want to consider. You could modify the run command and add options to allow parsing only and json formatted output. That way you can obtain all the errors from your editor instead of just compiler errors. You could set it to parse only if the input file is not specified. I don't know what kind of interface you'll be running in your editor to access the plcli so I don't know if this is a good suggestion or not.

Wouldn't the sub-command name parse be more appropriate than lint given the current code?
Sorry for the long post.feel free to ignore it since i am not reviewing anything.

[neptuwunium]

Did you know that the patter editor already does this and more?

Yes I am aware, but dealing with more than one pattern (which I am) the pattern editor gets cluttered fairly quickly. Along with ImHex having a non-zero chance of just randomly crashing because some struct was particularly badly formed, and not really having any concept of style enforcement (i.e. tabs vs spaces.)

It uses the parser to obtain information about definitions and declarations and uses them to parse the pattern semantically. You can't get that kind of static analysis from an external editor without a language server.

You are right, and I did note on this in the initial post. A full server implementing an LSP for hexpat would be nice, and it technically is possible due to the AST generated by pl, it's beyond what I'm willing to spend time for at this point.

You can open the pattern in the pattern editor and in your own editor at the same time and they will synchronize if you set your editor to track the file on disk.

Kind of a bit of a hassle when the entire thing is already extremely crammed. Especially when include order issues cause a massive error list.

You could modify the run command and add options to allow parsing only and json formatted output. That way you can obtain all the errors from your editor instead of just compiler errors.

Allow parsing only would still only yield compiler errors. The main burden for the evaluation errors is execution time (from needing and parsing a real file.)

Wouldn't the sub-command name parse be more appropriate than lint given the current code?

In this specific case it's just a semantic wording choice. I do agree that parse is technically more accurate.

[neptuwunium]

For pl to support a LSP properly there needs to be some refactors for the parser to keep going after an error, and just skip over the keyword.

Maybe in a few weeks when I have more mental energy I'll attempt wrapping the AST parser in something like ccls