search

fte-team / fteqw

This is the official GitHub mirror for the FTEQW project.
https://www.fteqw.org/
156 stars 47 forks source link

A way to run FTEQCC as a linter #176

Open vkazanov opened 1 year ago

vkazanov commented 1 year ago

While working on a little mod of my own I noticed that there is no way I can use FTEQCC as a linter on separate files, i.e. run the compiler with a path to a file (or a number of files) to check without actually generating the resulting bytecode file. This would make it possible to add warnings/error highlighting to an editor I use, as well as other editors used for the same purpose.

Am I missing something? Would the fte team be open to a pull request with such a feature..?

Thank you

PS I work on an Emacs extension providing some basic QuakeC support. Is there an explicit or implicit QuakeC grammar used by the fte-team? This would be very helpful in developing a TreeSitter grammar.

eukara commented 1 year ago

That sounds desirable, I think it would be appreciated by users of fteqccgui too if that was integrated. Pinging @Shpoike just in case.

vkazanov commented 1 year ago

I did a deep dive into fteqccgui, qcctui and qccmain. qclib, the compiler library, already supports a target "-Tparse", which omits emitting code and generating the .dat file. Moreover, unlike in the original qcc, the compiler is abstracted away into a library (qclib) that can be run in various contexts.

As such, qclib is deeply integrated with fteqccgui. It is used, for example, for FindDefinitions. As much as I can see from the code now (and I might be wrong) all the warnings and errors are just printed whenever the programmer decides to compile the project. But there's no live error/warning highlighting.

One option that could work already is running the compiler with "-Tparse" and looking up warnings/errors in the output. Limiting compilation to a single file is funny in QuakeC and its descendants as the language has this model of "include everything from a single .src".

The other option would be to come up with a separate command line utility (and maybe a qclib entry point) that would specialise in single file checking. I.e. something that could run like: "ftelqcclint path/to/file.qc". We'd have to tweak warning/error code a bit to segregate between warnings/errors that require broader context, and the ones that can be resolved based on local data.

Fteqccgui itself could benefit from the other option by integrating live linting... But given the already exsiting deep integration with the compiler it just doesn't make sense to run a subprocess for these purposes. It could run things directly.

@eukara what do you think?

eukara commented 1 year ago

Sorry for the delayed reply, I don't check GitHub often enough. I unfortunately have nothing to really provide in terms of insight, as @Shpoike is really the vision behind fteqcc and qclib... I hope he comes back onto his computer soon so he can provide his own perspective. As I understand there's some personal IRL stuff that's taken priority recently.

Shpoike commented 1 year ago

-Tparse just looks for (global)symbol definitions/includes. it is not do any real syntax checks, and even intentionally avoids looking too closely at any of the function bodies in order to avoid bailing early due to syntax errors. It is not appropriate for lint type things.

QC's compilation unit is the .src file, not the .qc file. trying to split it up will just hide too many warnings (out of necessity) for it to be useful. the instant you have some slightly weird #define anywhere the whole thing would become useless. or a struct, etc. it wouldn't even be able to validate args to builtins. a lint it would not be.

A hybrid approach should work, where it does only defs-parsing until it reaches the specific file you're interested in, whereupon it starts doing the proper function-level checks (then stopping with no file output) should work. This should be nippy enough for automatic use when editing, while also giving the appropriate error/warning indicators and minimising errors being ignored due to errors in the functions (albeit not defs) of earlier files. Probably it'd also need to pipe in some sort of archive instead of the single modified file, instead of constantly resaving. Or just use -o/tmp/deleteme.dat or whatever as an arg and accept the slower processing.

Adding it to fteqccgui too would be nice I guess, though not really all that different from just hitting f7 every now and then (which also ensures stuff gets saved periodically, so that's an extra win!).