[bug] "lint" mode doesn't work with stdin

[Taffer]

[Modified into a bug report from the previous feature request; I don't think we actually need a --config argument to specify the location of a .editorconfig.]

gdscript-formatter lint doesn't work in stdin mode; I couldn't tell if this was intentional or not:

# Guessed from the docs/--help output:

$ cat dice.gd | gdscript-formatter lint
Error: No GDScript files found in the arguments provided. Please provide at least one .gd file or directory containing .gd files.

# Another CLI convention:

$ cat dice.gd | gdscript-formatter lint -
Error: No GDScript files found in the arguments provided. Please provide at least one .gd file or directory containing .gd files.

Maybe a --stdin argument to force this? I couldn't tell from the code, I can't Rust yet.

[Taffer]

Coffee kicked in, and I'm now thinking that it's entirely possible that none of these settings:

[*.gd]
indent_size = 4
indent_style = space
insert_final_newline = true
max_line_length = 132
trim_trailing_whitespace = true

are going to affect lint mode output, except max_line_length. If that's the case, I should convert this into a bug report about gdscript-formatter lint not accepting input from stdin. 👍

[NathanLovato]

At the moment, I think, yes, that only the max line length is read for the linter. In general, the linter did not get a lot of work. I'm personally focusing on the formatter itself and the linter is a community contribution that I've worked on a little bit, mainly addressing bugs, but that's otherwise not gotten a lot of attention. Feedback on it are welcome as this is a type of tool I do not use myself (I find a linter focused on correctness and offering nearly real-time, pretty good static analysis really useful but this is not what it is currently).

[Taffer]

IMHO it's useful already, but my perspective might be a little skewed; in my day job I'm bouncing between Python, Go, C, Java, shell script, etc. all the time, and the GDScript best practices haven't had a chance to really sink into my brain yet.

I actually hadn't thought of adding lightweight static analysis to linters, I'm used to the static analysis step being expensive. This would be a pretty great research topic for a grad student in Computer Science… Someone with Copious Spare Time™ might be able to get some useful ideas from Python's ruff or Rust's clippy to add here as well.

[NathanLovato]

Good to know if it's useful, thanks for the feedback, and for the contributions too, I'll merge shortly.

I actually hadn't thought of adding lightweight static analysis to linters, I'm used to the static analysis step being expensive.

Yes! A lot of static analysis is really cheap to run (or rather computers are really fast).

Regarding work on a static analysis tool outside of Godot (NB: GDScript has its own analyzer inside Godot's core), some people are trying to do that. I've seen several projects that are sort of doing the same thing to some extent (GDShrapt is the oldest example really focused on that I think, written in C#, and Scony's gdscript-toolkit in Python included some static analysis in recent years I think). Some of them seem to be trying to grow into commercial offerings around an open source core.

But if a student had a lot of time and wanted to dedicate themselves to language development and surrounding tooling, I think I would direct them toward contributing to GDScript directly in Godot though perhaps GDScript would first need a full-time, experienced maintainer too to direct any contributions and the language compiler development itself.

Even this project, more generally anything that's part of the language toolchain, I don't think it's great that it's being made in another language or tech stack without coordination with the core team but right now you don't really have a choice. At least for this formatter hopefully by iterating over it it will provide a good specification and reference to rewrite in C++ the day it's wanted as part of an official toolchain, with the bulk of the work (i.e. iterating to get a reliable result) done.