Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The linter generates .plist files again #4703

Open
javiercarrascocruz opened this issue Jan 4, 2024 · 2 comments
Open

The linter generates .plist files again #4703

javiercarrascocruz opened this issue Jan 4, 2024 · 2 comments
Labels

Comments

@javiercarrascocruz
Copy link

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
Copy link
Author

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
Copy link
Contributor

Jorengarenar commented Feb 24, 2024

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'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants