New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance user experience by providing a linter for Chapel #9003
Comments
There is a Chapel plugin for both Vim and Atom Is that what you mean? |
That's for syntax highlighting, I mean something like this but for Chapel where it shows both warnings and errors that could only be caught via compilation. |
Oh, yeah. I've used jsonlint quite a bit. Thanks for explaining it. |
While developing this, I realize that a few additions are needed to improve this further...
|
Since you're the only one I'm comfortable calling on, do you have any idea on how to make it so that the Chapel compiler can optionally continue showing errors past the first it comes across? I know I can disable DeadCodeElimination through compiler flags to ensure the linter will show errors in 'dead' code, but if it requires changes to the Chapel compiler to make it show all errors do you have any pointers of where I should start. |
You could try using the I'll mention that, generally speaking, we're trying to not "halt compiler on first error" as much as we traditionally have, but that this has been a lazy and incremental change. That said, I think it's unlikely that we'd ever be comfortable, by default, listing multiple errors across multiple passes. I.e., if there are parse errors, I wouldn't expect future versions of the compiler to continue past parsing without an "I'm brave and can take what you throw at me" flag like |
Unfortunate |
This might simply be considered a bug to fix in |
To clarify, I understand why it will halt on parse errors and not continue on to static analysis, but even if a program is syntactically correct, if there is an error in pass A and another error in pass B, only the errors discovered in A will be emitted by the compiler which may catch users by surprise when after they fix it they see emission when the compiler halts on B. Although with the use of |
I agree on the need for a variant of |
I didn't know about |
Okay then, current goal to implement the following flags...
|
It would be nice for a linter to catch when user code uses an auto-used module, e.g. |
I think I would need the ability to query more information from the compiler to support something like this. For example: "Given a specific module X, what are the imports of X?" I could grep for the pattern myself too, but having such support from the compiler would be more resilient to language changes. |
Agreed. I just wanted to document the desire for that feature. |
I think of this as related to #7295. |
We have added a linter since this request was made, see: https://chapel-lang.org/docs/latest/tools/chplcheck/chplcheck.html Thanks especially to @DanilaFe and I believe @jabraham17 for all their hardwork (and I suspect I'm forgetting other names that have contributed to it) |
I believe that a linter should be provided for at least one text editor. A linter makes it significantly easier to program for both newcomers and experienced veterans in that it saves time by showing compiler errors and warnings on-demand without needing to manually compile (I.E Lint-On-Save). Although I am inexperienced with the actual creation of linters, after doing some digging around I believe I have discovered a simple example that can serve as the base for development. Using the Atom text editor as an example, providing an extension to the core AtomLinter package may not be too difficult as it seems to boil down to parsing the compiler output into a JSON Object that AtomLinter can process. Besides for other boilerplate code, I believe that this can be done and I do volunteer to create a simple prototype as I am very interested in having it myself.
There are some other issues that I believe would need to be addressed eventually, such as any internal errors that can arise... how should they be represented? Normal errors have the format "$FILE_PATH:$LINE_NUMBER: $ERROR_TYPE: $ERROR_MESSAGE", but would this be enough to catch all such errors and issues? Are there an other formats you'd need to look out for?
Screenshot of Progress:
Repository (WIP):
Available here: https://github.com/LouisJenkinsCS/Chapel-Linter
The text was updated successfully, but these errors were encountered: