| Age | Commit message (Collapse) | Author |
|---|
|
jonhoo-rust-analyzer
|
|
|
|
|
|
Changes in eclipselsp and java caused the command needed to run the
language server fail to build properly.
Thi PR fixes those issues.
|
|
|
|
|
|
linter/scala/metals: Fix return value of GetProjectRoot()
|
|
* Add terraform-lsp integration
https://github.com/juliosueiras/terraform-lsp
* Add tests & docs for terraform-lsp integration
terraform_langserver_options setting added to send custom flags to
terraform-lsp.
Vader tests have been added to test custom executable, custom flags, and
finding the project root. All tests pass.
Initial documentation has been added for the above.
Resolves dense-analysis/ale#2758, juliosueiras#57
* Fix tag alignment
Co-authored-by: = <Aubrey.S.Lavigne@gmail.com>
Co-authored-by: w0rp <w0rp@users.noreply.github.com>
|
|
Fix 3011 - not catching kotlinc output on stderr
|
|
Fixes #2621
|
|
It was returning 0 when it should be returning an empty string.
The 'AssertEqual' in the ale image is from an old version so it does not
check the types of the arguments.
This is already fixed in https://github.com/junegunn/vader.vim/commit/427fe19104c15066e4c1d5d385076e8e07a0dee8
Closes #3120
|
|
Since version 4.032 (04/2020) verilator linter messages also contain the
column number, and look like:
%Error: /tmp/test.sv:3:1: syntax error, unexpected endmodule, expecting ';'
To stay compatible with old versions of the tool, the column number is
optional in the researched pattern regular expression.
See commit:
https://github.com/verilator/verilator/commit/81c659957e89f28861fde870f000cce2d5f76729
|
|
Use stdin flag instead of temporary files. This allows ktlint to work
with .editorconfig files.
|
|
Use cache for clj-kondo linter
|
|
|
|
|
|
|
|
|
|
ALE appends flags from {c,cpp}_{clang,gcc}_options after those found by
parsing compile_commands.json or Makefile output. If -std=* flags are
present in both the ALE flags and parsed flags, the last one present
(i.e., ALE's -std=* flag) will determine the mode the compiler works in.
This can result in errors showing up in vim but not in the actual build
or vice-versa.
For example, say you have foo.cpp:
#include <type_traits>
int main() {
return std::is_same_v<float, int>;
}
If cpp_clang_options contains -std=c++17 and -std=c++14 is parsed from
compile_commands.json, then ALE would end up running something like:
clang++ -S -x c++ -fsyntax-only -std=c++14 -std=c++17 - < foo.cpp
This would result in no errors showing up in Vim, but the actual build
would fail with:
<stdin>:3:14: error: no template named 'is_same_v' in namespace 'std'; did you mean 'is_same'?
return std::is_same_v<float, int>;
~~~~~^~~~~~~~~
is_same
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/type_traits:872:61: note: 'is_same' declared here
template <class _Tp, class _Up> struct _LIBCPP_TEMPLATE_VIS is_same : public false_type {};
^
<stdin>:3:35: error: expected '(' for function-style cast or type construction
return std::is_same_v<float, int>;
~~~~~~~~~~~~~~~~~~~~~~~~~~^
2 errors generated.
as the actual build would not have the -std=c++17 flag added by ALE.
If cpp_clang_options contains -std=c++14 and -std=c++17 is parsed from
compile_commands.json, then the opposite problem would occur. ALE would
end up running something like:
clang++ -S -x c++ -fsyntax-only -std=c++17 -std=c++14 - < foo.cpp
and would show an error on line 3 of foo.cpp:
[clang] No template named 'is_same_v' in namespace 'std'; did you mean 'is_same'? (fix available)
The actual build, on the other hand, would succeed without any
complaints.
Removing -std=* from ALE's flags if it is already present in the parsed
flags ensures that the wrong -std=* flag is not used.
An alternative would have been to switch the order in which parsed flags
and ALE flags were concatenated when producing the command to execute,
but that could prevent a user from intentionally using ALE's flags to
override some other flags, e.g. -W* flags to enable/disable warnings in
a project whose flags are not under the developer's control.
-std=* flags are also present in cuda/nvcc.vim, objc/clang.vim,
objcpp/clang.vim, and vhdl/ghdl.vim, but none of those linters appear to
parse compile_commands.json or `make` output.
|
|
|
|
|
|
Fix for incorrect eslint output parsing for graphql files
|
|
* When deciding which directory to run mypy from, prefer a folder with mypy.ini in it
* Add a test for mypy.ini-finding behaviour
|
|
|
|
|
|
|
|
If checkstyle is configured with custom options that contain "-c" then
the checkstyle config file option is ignored. This PR modifies the
regular expression when creating the checkstyle command to avoid this.
|
|
The output is configured to be JSON, but the handler was parsing it as 'lines'
|
|
The shell linter does more than just bash.
|
|
Add StandardJS linter for TypeScript
|
|
|
|
Add nimcheck end_col options
|
|
This reverts commit f4070f6c43b3cb2e7463d8426a68d5a726991288.
|
|
Fix crystal-lang non file-tied message handling
|
|
nimcheck
|
|
Add the possiblity to add extra psalm options
|
|
clangcheck: Add -fno-color-diagnostics (closes #2188)
|
|
See https://github.com/standard/standardx
|
|
|
|
|
|
|
|
* Add support for nimlsp.vim
* Add test and docs for nimlsp
* Add nimlsp to supported-tools.md
* Add nimlsp to doc/ale-supported-languages-and-tools.txt
|
|
* Add definition of c/clangd's language as C
* Update tests for clangd to be called with '-x c'
* Change to use single quotes instead of double quotes
|
|
Fixes #2832
|
|
Some messages of the crystal compiler are not tied to a file.
This causes a 'Key not present in Dictionnary' error (E716).
For the record, the json output on ```require "./nonexistent.cr"```
is the following :
```json
[
{ "file":"/tmp/file.cr", "line":1, "column":1, "size":0,
"message":"while requiring \"./nonexistent.cr\"" },
{ "message":"can't find file './nonexistent.cr' relative to '/tmp'" }
]
```
The second message does not have line/column attributes.
|
|
|
|
|
|
|
|
|
|
* fix tflint handler for 0.11+
* fixup! fix tflint handler for 0.11+
* maintain compatibility with previous tflint output format
* fixup! maintain compatibility with previous tflint output format
* Add comment about tflint's output format accross versions
|
