| Age | Commit message (Collapse) | Author |
|---|
|
Fix elm-format fixer name
|
|
* Handle flawfinder severity level
* Reverted code allowing Flawfinder to piggyback off of gcc's format handler
* Gave Flawfinder its own format handler and made requested changes.
|
|
|
|
Support for elm-format as a fixer has existed since Sept 2017, but it's not
easy to discover because the fixer was named `format`. This breaks the
convention of the other fixers that use the full name in the registry.
I've gone ahead and fixed this discrepancy, but I left the existing registry
entry in place. We should move people towards using `elm-format` as the fixer
name, but I'd hate to break existing setups.
|
|
|
|
|
|
|
|
|
|
* If a Perl script compiles, there are only warnings and no errors
* Let the first Perl error or warning win.
Take the following example:
***
sub foo {
my $thing;
***
This might have the following messages when we compile it:
Missing right curly or square bracket at warning.pl line 7, at end of
line
syntax error at warning.pl line 7, at EOF
warning.pl had compilation errors.
With the current behaviour, we just get a "syntax error" message, which
isn't all that helpful. With this patch we get "Missing right curly or
square bracket".
* Fix variable scope and pattern matching syntax
* Use named variable to enhance clarity when matching Perl output
* Add more tests for Perl linter
* Remove unnecessary parens
* Simplify check for pattern match
|
|
|
|
|
|
add php-cs-fixer to list of fixers
|
|
|
|
* Add configuration option to open lists vertically
* Add tests, clean up vertical list config
* Vertical list option cleanup
* Use is# for tests
* Order properties in documentation alphabetically
|
|
|
|
* Flawfinder support added for C and C++
A minor modification to gcc handler was made to support flawfinder's
single-line output format that does not have a space following the
colon denoting the warning level. gcc handler still passes its
Vader tests after this modification.
* Documentation fixes
* Revert documentation regression
* Added Flawfinder to table of contents
* Removed trailing whitespace
* Follow ALE conventions better
Added additional documentation and Vader tests
|
|
This fixes issue #936 by linting the whole package
|
|
|
|
|
|
fixers
|
|
|
|
Add Support for Ponylang
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Call lintr library before linting
|
|
|
|
Improving hadolint checker
|
|
|
|
fixed rust errors parsing
|
|
|
|
|
|
|
|
[eruby] Add erubi linter
|
|
|
|
Add a luac linter for Lua
|
|
message for tsserver
|
|
* Also send didSave to LSP linters.
* Add tests for messages sent to LSP linters.
|
|
|
|
|
|
Erubi is yet another parser for eRuby. This is the default parser in
Rails as of version 5.1. It supports some additional syntax with similar
behavior to Rails' extensions to the language, though incompatible.
Rails currently still recommends their own syntax, so GetCommand still
has to do the translation introduced in
https://github.com/w0rp/ale/pull/1114 .
Erubi does not supply an executable—It is intended to be invoked only
from within a Ruby program. In this case, a one-liner on the command
line.
|
|
Make it possible to inject flags of protoc invocation.
|
|
test for ghc options
|
|
Fix #1255: Move extra clang-check args to before user options
|
|
Teach ALE about cargo features and add some configuration options
|
|
* When working on rust/cargo projects of varying sizes, it may be useful
to either build all possible features (i.e. lint all possible
conditionally compiled code), or even turn off other features for a
quicker edit-lint cycle (e.g. for large projects with large build times)
* Added a g:ale_rust_cargo_default_feature_behavior flag for instructing
cargo to not build any features at all (via `--no-default-features`),
building default features (via no extra flags), or building all possible
features (via `--all-features`)
* Also added a g:ale_rust_cargo_include_features flag for including
arbitrary features to be checked by cargo. When coupled with
g:ale_rust_cargo_default_feature_behavior this allows for full
customization of what features are checked and which ones are ignored
|
|
|
