Unimport (https://github.com/hakancelik96/unimport/) is a linter,
formatter for finding and removing unused import statements.
This introduces linting support, although fixer support could come
later.
More recent versions of thriftcheck use a more compliant GCC-style
output format which includes a space before the "severity" group.
This matches similar tools, like shellcheck.
This change adjusts the handler's pattern to parse this format in a
backwards-compatible way (even though backwards compatibility isn't
critical long-term as thriftcheck itself is close to its 1.0 release).
This User autocommand is trigged immediately after an LSP process is
successfully initialized. This provides a way to perform any additional
initialization work, such as setting up buffer-level mappings.
md5sum isn't available by default on macOS. Instead, it ships the
BSD-style md5(1) command, which does the same thing but with different
arguments.
With this change, run-tests works out-of-the-box on macOS.
Buildifier offers a -path command line option:
> Buildifier's reformatting depends in part on the path to the file
> relative to the workspace directory. Normally buildifier deduces
> that path from the file names given, but the path can be given
> explicitly with the -path argument. This is especially useful when
> reformatting standard input, or in scripts that reformat a temporary
> copy of a file.
This lets us drop our `-type`-guessing logic.
For the moment, we rely on the buffer filename being "relative to the
workspace directory", which it generally is, but in a future change, we
should introduce logic that will locate the WORKSPACE file and adjusts
the filename relative to that directory. This could be complicated based
on the working directory in which `buildifier` is executed, so a little
more research is necessary to implement that logic correctly.
This fixer enables buildifier's formatting and "lint fix" modes.
Additional options can be provided via `bazel_buildifier_options`.
It also implements some basic logic for guessing the file's type.
buildifier itself usually does this based on the filenames provided on
the command line, but because we're piping our buffer via stdin, we need
to do this manually.
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.
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.
Each LSP connection now stores its configuration dictionary. It is
initially empty (`{}`) and is updated each time the LSP connection is
started. When a change is detected, the workspace/didChangeConfiguration
message is sent to the LSP servers with the updated configuration.
This is the callback-based variant of the existing `lsp_config` linter
option. It serves the same purpose but can be used when more complicated
processing is needed.
`lsp_config` and `lsp_config_callback` are mutually exclusive options;
if both an given, a linter preprocessing error will be raised.
The runtime logic has been wrapped in `ale#lsp_linter#GetConfig` for
convenience, similar to `ale#lsp_linter#GetOptions`.
This also adds documentation and an `AssertLSPConfig` test function for
completeness.
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.
In a lint context, it's useful to assume that included files sit next to
the current file by default. Users can still further customize this
configuration variable to add more include paths.
This linter works by invoking the `thrift` compiler with the buffer
contents and reporting any parser and code generation issues.
The handler rolls its own output-matching loop because we have the
(unfortunate) requirement of handling error output that spans multiple
lines.
Unit tests cover both the command callback and handler, and there is
initial documentation for all of the option variables.
In particular, if we're working with a leex (.xrl) or yecc (.yrl) source
file, erlc would otherwise generate the corresponding .erl file in the
current directory (often the project root), which is generally not what
we want.
Unconditionally writing erlc output to a temporary directory also
matches Flycheck's behavior.
* Fix Credo's line-matching pattern
In d3e7d3d5, the line matching pattern was changed to handle filenames
other than `stdin`. Unfortunately, this broke the pattern's ability to
reliably extract both line and column numbers because the latter is an
optional match and the filename portion was very greedy. This resulted
in line numbers being discarded (treated as part of the filename) and
column numbers being interpreted as line numbers.
This change simplifies the pattern to only anchor on the line's suffix,
ignoring the filename portion entirely.
Alternatively, we could use vim's `\f` ("file name characters") class,
but that could still run into problems when `:`'s naturally appear in
the filename.
* Add a Vader test case for the Credo handler
By default, Credo attributes input from STDIN as though it came from a
file named `stdin`. This change passes the buffer's filename, too, so
that Credo can use that information when applying its configuration.
This is a nice improvement because files like `mix.exs` are normally
excluded from Credo-based linting. Previously, ALE would show lint
warnings for those files as they were edited. Now, they are correctly
honor the Credo configuration and don't produce lint output.
Jon Parise