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.
* 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
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.
* The project style linter now runs while you type.
* Now the scripts for checking the project require blank lines.
* Many style issues have been found and fixed.
