dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.48k stars 1.43k forks source link

The linter generates .plist files again #4703

Open javiercarrascocruz opened 8 months ago

javiercarrascocruz commented 8 months ago

I just updated ALE (running the master branch) and every time I open a *.c file in a project that contains a compile_commands.json, a .plist file with the name of the file I opened is created in the project's root directory (i.e. build directory where the compile_commands.json resides). Apparently this is not the first time the issue arises: #703

Back then the arguments passed to clang-check were extended to solve the issue. I see that the ale_linters/c/clangcheck.vim with a call to clang-check was added in December and it uses other arguments, but I don't know the tool enough to tell what is right and what is wrong.

I can only confirm that this did not happen with the master branch of ALE 6 months ago when I installed the plugin.

I made sure that no other plugin generates the .plist files and checked that if ALE is removed, the .plist files are not created anymore.

Information

VIM version VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 05 2023 17:29:58) Included patches: 1-1000, 1087, 1117-1118, 1129, 1165, 1143-1145, 1189, 1530, 1840, 1846-1848, 1857, 1331, 1858, 1873, 1969, 1992, 2010, 2068, 2106, 2108-2109, 1512, 1729, 1747, 2107, 2110-2

Operating System: Ubuntu 23.04

What went wrong

Opening files generates *.plist counterparts in the project's root directory, which did not happen before (at least up to 6 months ago).

Reproducing the bug

  1. Generate a compile_commands.json file for a C project.
  2. Open a C file.
  3. A .plist file with the same name is created in the project's root directory where compile_commands.json resides.

If there is no compile_commands.json file, the file is not generated.

:ALEInfo

Current Filetype: c
Available Linters: ['cc', 'ccls', 'clangcheck', 'clangd', 'clangtidy', 'cppcheck', 'cpplint', 'cquery', 'cspell', 'flawfinder'] Linter Aliases:
'cc' -> ['gcc', 'clang']
Enabled Linters: ['cc', 'ccls', 'clangcheck', 'clangd', 'clangtidy', 'cppcheck', 'cpplint', 'cquery', 'cspell', 'flawfinder'] Ignored Linters: ['ccls', 'clangd', 'cquery']
Suggested Fixers:
'astyle' - Fix C/C++ with astyle.
'clang-format' - Fix C, C++, C#, CUDA, Java, JavaScript, JSON, ObjectiveC and Protobuf files with clang-format. 'clangtidy' - Fix C/C++ and ObjectiveC files with clang-tidy.
'remove_trailing_lines' - Remove all blank lines at the end of a file.
'trim_whitespace' - Remove all trailing whitespace characters at the end of every line.

javiercarrascocruz commented 8 months ago

I played around with the ale_linters/c/clangcheck.vim and I can confirm that if the the same arguments are used if the build directory is detected, the .plist files are not created anymore:

    return '%e -analyze %s'
    \   . (empty(l:build_dir) ? ' --extra-arg=-Xclang --extra-arg=-analyzer-output=text --extra-arg=-fno-color-diagnostics': '')
    \   . ale#Pad(l:user_options)
    \   . (!empty(l:build_dir) ? '--extra-arg=-Xclang --extra-arg=-analyzer-output=text --extra-arg=-fno-color-diagnostics -p ' . ale#Escape(l:build_dir) : '')

That is obviously a hack, but someone who knows what is really going on could probably either code it clean or explain the observed behavior. I just copied the arguments without really knowing how clang-check works or even VimScript at all.

But hopefully this still helps.

Jorengarenar commented 6 months ago

One way to fix that would be to add those arguments unconditionally:

    return '%e -analyze %s'
    \   . ' --extra-arg=-Xclang --extra-arg=-analyzer-output=text --extra-arg=-fno-color-diagnostics'
    \   . ale#Pad(l:user_options)
    \   . (!empty(l:build_dir) ? ' -p ' . ale#Escape(l:build_dir) : '')

As a workaround you can set the following in your config:

let g:ale_c_clangcheck_options =  ' --extra-arg=-Xclang --extra-arg=-analyzer-output=text --extra-arg=-fno-color-diagnostics'