| Age | Commit message (Collapse) | Author |
|---|
|
PMD is currently not working properly for Java classes that use [unnamed
packages](https://docs.oracle.com/javase/specs/jls/se11/html/jls-7.html#jls-7.4.2).
Consider the following Java class that does not contain a `package`
declaration:
```java
public class App {
String getGreeting() {
return "Hello world.";
}
static void main(String... args) {
System.out.println(new App().getGreeting());
}
}
```
Running PMD in the command line agaist the Java class above produces an
output with empty string `""` in the `"Package"` column:
```sh
$ pmd -R category/java/bestpractices.xml -f csv -d './src/main/java/App.java'
Oct 02, 2018 9:10:39 PM net.sourceforge.pmd.PMD processFiles
WARNING: This analysis could be faster, please consider using Incremental Analysis: https://pmd.github.io/pmd-6.7.0/pmd_userdocs_incremental_analysis.html
"Problem","Package","File","Priority","Line","Description","Rule set","Rule"
"1","","/Users/diego/Projects/github.com/dlresende/kata-fizz-buzz/src/main/java/App.java","2","7","System.out.println is used","Best Practices","SystemPrintln"
```
But the pmd.vim handler's current pattern refuses everything coming
from a Java class that does not have a package name (2nd column):
```vim
let l:pattern = '"\(\d\+\)",".\+","\(.\+\)","\(\d\+\)","\(\d\+\)","\(.\+\)","\(.\+\)","\(.\+\)"$'
```
The solution I am proposing is to also accept empty strings as package names.
|
|
These test vars were covering up a bug in the hlint linter
implementation. Without these vars we can see the behavior that is
exhibited in `vim` proper.
|
|
* Add better support for Haskell stack compiler tools
This commit adds support for `stack` as the executable of a tool. This
follows a pattern that has been implemented for `bundler`'s tool chain.
* Move hlint command to linter file
* Add vader test for stack exec handling
* Update ghc-mod to support stack execution
`ghc-mod` was previously broken into 2 linters.
1. ghc_mod
2. stack_ghc_mod
This additional linter is not necessary with proper support for
executable variables and `stack exec` handling.
* Support stack exec in hfmt
* Support stack in hdevtools
|
|
Add ccls support for C/C++/ObjC
|
|
Support options when using Stylelint with SCSS
|
|
|
|
|
|
|
|
Allow extra options to be passed to haskell:hlint
|
|
* Don't add newlines when not a control statement for Python
* Add test for accidental newline fix
* Add docstring detection to avoid adding unnecessarily newlines
* Add tests for docstring detection
|
|
shfmt: Use Vim's indent config as default indent width
|
|
Add python_[linter]_auto_pipenv options for python linters (fixes #1656)
|
|
* Add fixer for Go modules
|
|
|
|
Closes #1931
|
|
c#ParseCFlags: don't index empty list
|
|
Support Solargraph stdio
|
|
To avoid blocking build tools, suspend ALE when suspending vim
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
thrift: default thrift_thrift_includes to ['.']
|
|
|
|
|
|
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.
|
|
When set to true, and the buffer is currently inside a pipenv,
GetExecutable will return "pipenv", which will trigger the existing
functionality to append the correct pipenv arguments to run each linter.
Defaults to false.
I was going to implement ale#python#PipenvPresent by invoking
`pipenv --venv` or `pipenv --where`, but it seemed to be abominably
slow, even to the point where the test suite wasn't even finishing
("Tried to run tests 3 times"). The diff is:
diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim
index 7baae079..8c100d41 100644
--- a/autoload/ale/python.vim
+++ b/autoload/ale/python.vim
@@ -106,5 +106,9 @@ endfunction
" Detects whether a pipenv environment is present.
function! ale#python#PipenvPresent(buffer) abort
- return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# ''
+ let l:cd_string = ale#path#BufferCdString(a:buffer)
+ let l:output = systemlist(l:cd_string . 'pipenv --where')[0]
+ " `pipenv --where` returns the path to the dir containing the Pipfile
+ " if in a pipenv, or some error text otherwise.
+ return strpart(l:output, 0, 18) !=# "No Pipfile present"
endfunction
Using vim's `findfile` is much faster, behaves correctly in the majority
of situations, and also works reliably when the `pipenv` command doesn't
exist.
|
|
|
|
fix non-. prefix triggers overfiltering results
|
|
Update all Ruby linters to work consistently with bundler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add support for sqlfmt
|
|
add uncrustify fixer for several languages
|
|
|
|
|
|
|
|
|
|
|
|
Add solargraph.yml file as root path search file.
|
