| Age | Commit message (Collapse) | Author |
|---|
|
See: https://github.com/testdouble/standard
StandardRB is to RuboCop what StandardJS is to ESLint. This commit
naively copies the RuboCop linter and fixer to point at the standardrb
executable. Any other adjustments are very minor (the only I can think
of is that standardrb takes a `--fix` option instead of
`--auto-correct`).
This raises a confusing point to me as both developer and a user: since
ale enables all linters by default, won't this run both RuboCop and
StandardRB (the results of which will almost always be in conflict with
one another)? How does ale already solve for this for the similar case
of StandardJS and ESLint?
|
|
It's common to add SwiftLint as a CocoaPod dependency, instead of as a global
binary. In this case we should use that version of SwiftLint before looking
for any others. Note that I'm also adding support for SwiftLint in ReactNative
projects here as well, where the Pods directory would be nested inside an ios
directory.
|
|
Add bibclean fixer support
|
|
The linter can correctly parse pydocstyle output with any of the following
command-line options enabled: --explain, --source, --debug, and/or
--verbose
|
|
Previous implementation required one to have sass-lint globally. This
allows you to have it locally, override the executable and add options.
|
|
The command used to invoke the LSP process was being escaped wrong.
Also added a new option to set a different java executable and fixed the
documentation.
|
|
This reverts commit 1c89495d771ec6518599bea83dd11a7c1d66ba73, reversing
changes made to 4b4b09593b2b090282981d69a9647a3c91d1f8b9.
|
|
Closes #1910
|
|
flake8 reports visual columns
|
|
* php: change phpstan's --errorFormat to --error-format
* add version check to phpstan
|
|
Fixes #2092.
|
|
Add linter for ispc
|
|
|
|
Continue scalac compilation until just before bytecode generation
|
|
Add GCC linter for Ada
|
|
|
|
Previous behavior does not compile deep enough to surface errors.
See compiler phases:
https://docs.scala-lang.org/overviews/compiler-options/index.html#compilation-phases
|
|
Vale supports AsciiDoc. This patch adds a Vale linter for AsciiDoc
files, which is based on the existing Markdown linter.
|
|
|
|
|
|
Checkstyle improvements
|
|
|
|
Temporary files break checks like the one for a missing
package-info.java, as discussed in #1305.
|
|
The output format used by older checkstyle versions differs from the one
of new versions. This commit adds a second parsing iteration on the
output lines with a suitable pattern to support both versions in
parallel. Due to the differences in the order of matching groups this is
hard to achieve in a single pass through the output lines.
An appropriate test case is added.
|
|
Previously, elixir-ls would treat each sub-project within an umbrella as
standalone, which isn't desirable from a language server perspective.
Added ale#handlers#elixir#FindMixUmbrellaRoot, which locates the current
project's root and then continues searching upwards for a potential
umbrella project root. This literally looks just two levels up to keep
things simple while keeping in line with Elixir project conventions.
Use this new function to determine elixir-ls's LSP project root.
|
|
Add initial support for ruumba in eruby files.
|
|
* Allow configuration of hamllint executable
The hamllint executable was hard-coded, preventing it from being
overridden. Fix the executable to be dynamic to allow custom executable
paths.
|
|
PHP linter: make the path to the executable configurable
|
|
Ruumba provides RuboCop linting for ERB templates.
https://github.com/ericqweinstein/ruumba
|
|
Fixes #1388
|
|
This adds generic configuration dictionary support to the elixir-ls
linter. This is useful for disabling its built-in Dialyzer support, for
example, which can improve startup time.
The configuration dictionary is a little verbose. I considered reducing
the user configuration to only the nested settings dictionary (and
having the linter implementation wrap it in the top-level `elixirLS`
dictionary), but leaving it fully configurable simplifies the code and
removes any assumptions about current or future ElixirLS behavior.
|
|
Pass the filename of the current file into jshint
|
|
|
|
|
|
* Add the dockerfile_lint linter for Dockerfiles
|
|
* add prolog/swipl linter
* use load_files/2 instead of read_term/2
Because it also checks some semantic warnings / errors
not only syntactic warnings / errors.
e.g.:
* singleton warning
* discontiguous warning
* ...
cf. http://www.swi-prolog.org/pldoc/doc_for?object=style_check/1
* support error messages with no line number
:- module(module_name, [pred/0]).
causes
ERROR: Exported procedure module_name:pred/0 is not defined
* add test for prolog/swipl handler
* cosmetic fixes
* detect timeout using SIGALRM
* rename g:prolog_swipl_goals to g:prolog_swipl_load
* write doc for prolog/swipl linter
* update toc and README
* fix ignore patterns
|
|
|
|
Add Perl6 support via 'perl6 -c'
|
|
* Only run stack if a stack.yaml config is found
It is necessary to check for a stack.yaml file to distinguish between
cabal-only projects or stack projects (which are also cabal projects
since stack is built on top of cabal).
* Test that stack is called if stack.yaml exists
|
|
Update Psalm to use LSP
|
|
* Add support for `cargo clippy`
* Add tests for cargo-clippy support
* Add an example to doc for how to configure ale_rust_cargo_use_clippy
|
|
|
|
Expose ruby-solargraph's initialization options
|
|
* Allow custom executable for ansible linters
* Add ansible-lint tests
* ansible-lint: simplify linter command
* Rename linter "ansible" to "ansible_lint"
* Add ansible-lint options to documentation
* Add alias ansible-lint for ansible_lint
|
|
* New linter: dls
|
|
|
|
|
|
ElixirLS (https://github.com/JakeBecker/elixir-ls) is an LSP server for
Elixir. It's distributed as a release package that can be downloaded
from https://github.com/JakeBecker/elixir-ls/releases or built locally.
The easiest way to start it is via Unix- and Win32-specific helper
scripts, so that's the basis of this command integration. Alternatively,
we could implement the contents of those platform-specific scripts in
the linter's command callback in a language-neutral way, but there isn't
any benefit to doing that aside from eliminating the platform check, and
that could prove to be too tight of a coupling going forward.
|
|
* Add more Credo message types
* Add tests
|
|
* FIX: use mix from the project root directory
* Move find root project function to autoloaded handlers
* add tests for #ale#handlers#elixr#FindMixProjectRoot
|
