Looks like elm-make only respects /dev/null, even on Windows. The person
who wrote this linter maybe did not test it on Windows, and wrote the
code in the way you would expect to be solid by using NUL on Windows.
However it seems elm-make is not actually making use of /dev/null but
rather using it as a form of flag. Ironically this seems to be what is
already described in the comments; I added some clarification.
Implements suggestions and recommendations suggested by the first review
of the "Advance C# linter based on mcs -t:module (#952)" pull request.
- Clarifies and simplifies description of linters and options
- Added links to help file and marked the mcsc linter as to be run only
when file in buffer is saved or loaded.
- Added comments to the mcsc.vim file to clarify code
- removed type checks considered not necessary be reviewer.
- addresses findings by vader
- removed call to getcwd and cd in vim script
- handler expands file names relative to route of source tree into
absolute pathes. Fixes errors not being marked when vim is started
from subdirectory of source tree.
- implements tests for mcs.vim and mcsc.vim linter
The existing c-charp linter used the --syntax check mode of the mono mcs
compiler only. The new mcsc linter tries to compile the files located in
a directory tree located bejond the specified source directory or the
current one if no source is explicitly specified. The resulting module
target is placed in a temporary file managed by ale.
This fixes slim-lint not honoring a `.rubocop.yml` in the file's or
parent directory. Due to the way slim-lint calls rubocop, it requires
the special `SLIM_LINT_RUBUCOP_CONF` env var to pick up the
`.rubocop.yml` if it is not run on the real file (which is the case
here).
See https://github.com/sds/slim-lint/blob/master/lib/slim_lint/linter/README.md#rubocop
* Detect and use CM files for smlnj
* Split into two checkers
- one for CM projects
- one for single SML files
* Fix some typos
* Fix error caught by writing tests
We want to actually use `glob` to search in paths upwards from us.
(Previously we were just searching in the current directory every time!)
* Fix errors from former test run
* Write tests for GetCmFile and GetExecutableSmlnj
* Typo in 'smlnj/' fixture filenames
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.
Right now ghc-mod linter check temp file instead of current buffer,
which cause the problem that it can't detect cabal file and raise
missing package error.
To fix that we need to run ghc-mod check with actual path of the current
file and with ghc-mod option `--map-file` to redirect temp file source
code to actual one
A limited number of clang-tidy checks can be used with C, too. I pretty much
copied and refactored the C++ clang-tidy linter, and added some documentation
about C-compatible checks.
* Add support for scalastyle
* Add scalastyle docs
* scalastyle support for column numbers
* off by one column
* Add tests for scalastyle command and handler
* update readme for scalastyle
* allow full scalastyle options instead of just config file
* fix indentation
* allow scalastyle config file in parent directories by a couple names.
* check for missing match args with empty
* remove echo
* use a for loop
The handler previously assumed there would be at least one entry in the
'files' array in the output JSON. It looks like this in the normal case:
"files":[{"path":"app/models/image.rb","offenses":[]}]
But if RuboCop's config excludes the specified input files, causing no
files to be linted, the output is emptier:
"files":[]
This change causes the handler to treat that case correctly, and also
exit early if the reported offense_count is zero.
* Move FindRailsRoot() to more general location
* Add rails_best_practices handler (resolves#655)
* Update documentation for rails_best_practices
Also add brakeman to *ale* documentation.
* rails_best_practices: allow overriding the executable
* rails_best_practices: format help correctly
* rails_best_practices: capture tool output on Windows
The real fix was not using absolute paths anymore (so not expanding with the `:p` option). The regex was correct and should at least include the `^` character to make sure the string starts with the given path/filename and not references the path/filename in some error description.
* Vim scripts shouldn't have hyphens
Especially not ones that will be autoloaded. You can't have a hyphen in
a function name, so autoloading functions based on filename will fail.
* Add g:haskell_stack_build_options, default: --fast
If we're going to use the --fast option, we may as well go the whole 9
yards and let the user configure the 'stack build' flags.
* Create documentation for stack-build options
* Add stack-build linter for Haskell
The stack-build linter works better than the other two linters when
you're working with an entire Haskell project. It builds the project
entirely and reports any errors.
The other two Haskell GHC linters only work on single files, which can
result in spurious errors (for example, not being able to find imports).
* Document all available Haskell linters
* Split GHC checkers into separate files
* Use rubocop's JSON output format (resolves#339)
Rubocop's emacs formatter seems to have changed format in some
not-so-ancient version. The JSON formatter should provide a more stable
interface than parsing lines with a regex.
The JSON formatter was introduced in mid-2013, so it should be safe to
assume available in any reasonably-modern environment. The oldest
currently-supported version of ruby (according to ruby-lang.org) was
not supported by rubocop until 2014.
* Rubocop: Use global function for GetType
* Rubocop: Use scope prefix in GetType
* Rubocop: Update command_callback test
* Rubocop: add end_col to Handle
* Use different reporter to support older versions of jscs
* Add test and make more consistent with other code
* Add documentation for jscs
* Add more test coverage
* Add documentation for hadolint (doc/ale-hadolint.txt)
* Allow `hadolint` linter to run via docker image
These changes enable the `hadolint` linter to run via the author's
docker image, if present. Three modes are supported:
* never use docker;
* always use docker; and
* use docker as a failback.
* Adds an option to pass additional arguments to the verilog/verilator linter
The new otion is g:ale_verilog_verilator_options
+ doc
* Spell check verilog linter doc file
* Add entries to the verilog linters in the doc table of content
* Vader test for verilog/verilator linter args option verilog_verilator_options
* Improve elm linter
Some types of errors do not return nice JSON.
Show them on the first line instead of showing nothing.
* Remove unnecessary properties from elm linter
* Add a vader test for elm-make linter
* Test non-JSON elm-make errors are shown
* Add column number to perlcritic linting output
This returns the column number of the perlcritic error so that ale can
show the column in addition to the line where perlcritic found an error.
* Add perlcritic configuration for rule names
This adds a configuration setting so that the name of the perlcritic
rule is shown [Rule::Name] after the error message.
This is useful to lookup the rule failure.
* Add a vader test for perlcritic#GetCommand
* Add ktlint support (without formatting) for kotlin filetype
* Fix code style and refactor to use ALE utility functions (GetMatches)
* Remove options for configuration file
* Refactor: Rename exec variable and use ale#Set for variable configuration
"-X Disables all warnings regardless of use warnings or $^W". See
"perldoc perlrun" or http://perldoc.perl.org/perlrun.html
With the current defaults, warnings are squashed. For example:
$ perl -X -Mwarnings -c -e'BEGIN { 42 + undef }'
-e syntax OK
$ perl -Mwarnings -c -e'BEGIN { 42 + undef }'
Use of uninitialized value in addition (+) at -e line 1.
-e syntax OK
So, it's not clear from the current defaults whether Ale wants to remove
warnings or enable them. As it stands, it's trying to do both and the
disabling appears to win.
This commit enables warnings by default.
