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.
The standard linter --fix fails if the file being input is not relative
to the project root (https://github.com/standard/standard/issues/1384).
This MR attempts to fix this by changing the command so the input file
is relative to the project root and the output is to a temporary file.
Preliminary tests with toy javascript projects seem to indicate this
works fine.
* Refactor the "s:LoadArgCount()" function
Previously, this function would always set "v:errmsg" on the first
call with a given function. This is because autoloaded functions
are not defined on the first call.
A number of improvements have been made:
- a useless local function ("l:Function") is removed
- the "execute()" builtin captures the output, instead of ":redir"
- a ":try" block handles the case where a function is not defined
- a useless ":if" is removed since ":redir" always defines the var
- confusing quoting is re-written (remove double "'" chars)
Fixes: #3021
Rather than requiring users to alias ps1 to powershell themselves,
include it in s:default_ale_linter_aliases. Since [vim-ps1] is a
popular (the only?) PowerShell ftplugin and there do not appear to be
any other uses of ft=ps1 on vim.org, this seems like a safe and
reasonable default.
[vim-ps1]: http://www.vim.org/scripts/script.php?script_id=1327
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
This is kind of a peculiar reason for a PR, but I no longer control the email listed. I want to change it to avoid people getting the wrong email for me. Also, I still control the domain, but if at any point I don't, I want to put down in writing that if you get an email from this, it's not from me.
* Add autoimport support for deoplete
* Fix test_deoplete_source.py
* Use callback instead of is_async for deoplete
Shuogo, the author of Deoplete, does not recommend using the `is_async`
option:
> I think is_async is not recommended. It is not so useful and broken.
> You should use callback system instead.
Link: https://github.com/Shougo/deoplete.nvim/issues/1006#issuecomment-526797857
Incidentally, the same thread mentiones an issue started by w0rp:
https://github.com/Shougo/deoplete.nvim/issues/976
The deoplete docs also say is_async is deprecated:
> is_async (Bool)
> If the gather is asynchronous, the source must set
> it to "True". A typical strategy for an asynchronous
> gather_candidates method to use this flag is to
> set is_async flag to True while results are being
> produced in the background (optionally, returning them
> as they become ready). Once background processing
> has completed, is_async flag should be set to False
> indicating that this is the last portion of the
> candidates.
>
> Note: The feature is deprecated and not recommended.
> You should use callback system by
> |deoplete#auto_complete()| instead.
Link: https://github.com/Shougo/deoplete.nvim/blob/master/doc/deoplete.txt
Co-authored-by: w0rp <w0rp@users.noreply.github.com>
ESLint 6 loads all plugins/configs/parsers relative to the project root
which, by default, is the directory in which ESLint is invoked, as
described in [ESLint RFC 2018-simplified-package-loading].
Therefore, ALE should run ESLint from the project root, when possible,
so that dependencies will load. This commit does so.
[ESLint RFC 2018-simplified-package-loading]: https://github.com/eslint/rfcs/blob/master/designs/2018-simplified-package-loading/README.mdFixes: #2787
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Before this change, prettier_standard would run and ignore any
.prettierrc, now it will respect the configuration of the file being
linted.
This change relies on prettier-standard 16.1.0 for the --stdin-filepath
flag, but is backward compatible: older versions of prettier-standard
will ignore the unknown flag and continue to run with no configuration
file.
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.
ESLint errors are contained in an array that can contain different
stuff other than JSON error messages. This patch iterates over the whole
array ignoring any non-json data.
Some files lack a hashbang line but still have an unambiguous filetype.
For example, the file `.zshrc` has the filetype `zsh`.
Augment ale#handlers#sh#GetShellType to fall back to the filetype if
no hashbang line can be found.
