marc/ale
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
This repository has been archived on 2024-07-19. You can view files and clone it, but cannot push or open issues or pull requests.
ale/ale_linters/c/cc.vim

54 lines
1.6 KiB
VimL
Raw Normal View History

Add comment headers to ale_linters
2016-10-03 18:55:55 +00:00
" Author: w0rp <devw0rp@gmail.com>
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
" Description: A C compiler linter for C files with gcc/clang, etc.
Add comment headers to ale_linters
2016-10-03 18:55:55 +00:00
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
call ale#Set('c_cc_executable', '<auto>')
call ale#Set('c_cc_options', '-std=c11 -Wall')
#711 - Make the gcc executables configurable
2017-07-16 21:41:15 +00:00
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
function! ale_linters#c#cc#GetExecutable(buffer) abort
let l:executable = ale#Var(a:buffer, 'c_cc_executable')
" Default to either clang or gcc.
if l:executable is# '<auto>'
if ale#engine#IsExecutable(a:buffer, 'clang')
let l:executable = 'clang'
else
let l:executable = 'gcc'
endif
endif
return l:executable
endfunction
function! ale_linters#c#cc#GetCommand(buffer, output) abort
Added additional unit tests + adapted review comments #1167
2018-03-21 19:44:35 +00:00
let l:cflags = ale#c#GetCFlags(a:buffer, a:output)
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
let l:ale_flags = ale#Var(a:buffer, 'c_cc_options')
Avoid overriding parsed C/C++ -std=* flag 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.
2020-03-17 22:00:47 +00:00
if l:cflags =~# '-std='
let l:ale_flags = substitute(
\ l:ale_flags,
\ '-std=\(c\|gnu\)[0-9]\{2\}',
\ '',
\ 'g')
endif
Fix #557 - Detect C project roots and include root directories with headers, or include directories
2017-05-31 19:01:40 +00:00
#277 #318 Support all same-directory includes for gcc and clang
2017-03-11 16:47:32 +00:00
" -iquote with the directory the file is in makes #include work for
" headers in the same directory.
Fix #2512 - Use -o /dev/null for gcc linting
2019-05-20 12:00:32 +00:00
"
" `-o /dev/null` or `-o null` is needed to catch all errors,
" -fsyntax-only doesn't catch everything.
return '%e -S -x c'
\ . ' -o ' . g:ale#util#nul_file
Close #3325 - Apply new formatting where possible
2020-08-28 18:50:36 +00:00
\ . ' -iquote %s:h'
Add support for parsing compile_commands.json files for C compilers
2018-07-29 18:24:19 +00:00
\ . ale#Pad(l:cflags)
Avoid overriding parsed C/C++ -std=* flag 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.
2020-03-17 22:00:47 +00:00
\ . ale#Pad(l:ale_flags) . ' -'
Added ability to reload compilation flags for c and c++ after loading plugin
2016-12-23 23:17:01 +00:00
endfunction
First pass at optimizing ale to autoload (#80) * First pass at optimizing ale to autoload First off, the structure/function names should be revised a bit, but I will wait for @w0rp's input before unifying the naming style. Second off, the docs probably need some more work, I just did some simple find-and-replace work. With that said, this pull brings major performance gains for ale. On my slowest system, fully loading ale and all its code takes around 150ms. I have moved all of ale's autoload-able code to autoload/, and in addition, implemented lazy-loading of linters. This brings load time on that same system down to 5ms. The only downside of lazy loading is that `g:ale_linters` cannot be changed at runtime; however, it also speeds up performance at runtime by simplfying the logic greatly. Please let me know what you think! Closes #59 * Address Travis/Vint errors For some reason, ale isn't running vint for me... * Incorporate feedback, make fixes Lazy-loading logic is much improved. * Add header comments; remove incorrect workaround * Remove unneeded plugin guards * Fix lazy-loading linter logic Set the wrong variable.... * Fix capitialization
2016-10-10 18:51:29 +00:00
call ale#linter#Define('c', {
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
\ 'name': 'cc',
\ 'aliases': ['gcc', 'clang'],
Add support for checking C code with GCC too.
2016-09-18 18:33:33 +00:00
\ 'output_stream': 'stderr',
#3299 Merge gcc and clang into a cc linter Users can easily be confused when they set some options for a C or C++ compiler, and another compiler is run with different options, which still reports errors. To remedy this, the existing `gcc` and `clang` linters have been replaced with a `cc` linter that will run either compiler. This is a breaking change for ALE v3.0.0.
2020-08-20 00:46:29 +00:00
\ 'executable': function('ale_linters#c#cc#GetExecutable'),
\ 'command': {b -> ale#c#RunMakeCommand(b, function('ale_linters#c#cc#GetCommand'))},
Indicate that a C compiler failed due to problems in a header file
2018-07-30 19:09:43 +00:00
\ 'callback': 'ale#handlers#gcc#HandleGCCFormatWithIncludes',
Add support for checking C code with GCC too.
2016-09-18 18:33:33 +00:00
\})
Reference in a new issue Copy permalink