[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs + bear + compile_commands.json + clangd
From: |
Matt Armstrong |
Subject: |
Re: Emacs + bear + compile_commands.json + clangd |
Date: |
Tue, 11 Oct 2022 10:37:38 -0700 |
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Matt Armstrong <matt@rfc20.org> writes:
>
>> Hey João, I had issues with Emacs source and clangd, especially with
>> header files. The issue is that many of Emacs' C header files are not
>> "self contained" so they can't be compiled alone. Also, `bear` will
>> only generate compile commands for .c files, and clangd uses
>> heuristics to guess a compile command for nearby .h files. It does a
>> reasonable job in some projects, but not Emacs due to the "self
>> contained" issue. Biggest issue: when editing an .h file clangd won't
>> include <config.h> for you.
>
> I'm wondering how you use clangd. Is this lsp-mode or eglot? I'm using
> lsp-mode ATM, just because I tried it first, and it worked for me.
I use eglot because I tried it first and it worked for me. ;-)
I tried eglot first because I like the general design philosophy of
integration with core Emacs packages and a more conservative approach to
the UI. You barely know when eglot is running!
>> I now do this:
>>
>> ./configure <whatever>
>> bear --force-wrapper -- make -j$CPUS
>> emacs-fixup-compile-commands.py
>>
>> where emacs-fixup-compile-commands.py is attached. Bonus to anyone
>> rewrites it in elisp. ;-)
>
> I've never had to use --force-wrapper or alter compile_commands.json.
Regarding compile_commands.json, if I use the compile_commands.json
generated by bear, with eglot, with clangd version "Debian clangd
version 14.0.6-2", it works well for .c files but not .h files.
E.g. I open src/buffer.h and I get these errors in flymake (this is a
small subset):
26 9 error e-f-b clang [unknown_typename]: In included file: unknown
type name 'INLINE_HEADER_BEGIN'
1 0 error e-f-b clang [fatal_too_many_errors]: Too many errors
emitted, stopping now
283 4 error e-f-b clang [unknown_typename]: Unknown type name
'INTERVAL'
722 9 warning e-f-b clang [-Wimplicit-function-declaration]: Implicit
declaration of function 'PSEUDOVECTORP' is invalid in C99
877 5 warning e-f-b clang [-Wimplicit-function-declaration]: Implicit
declaration of function 'NILP' is invalid in C99
1079 26 error e-f-b clang [expr_not_ice]: Expression is not an integer
constant expression
1256 7 error e-f-b clang [unknown_typename]: Unknown type name
'INTERVAL'
1573 14 warning e-f-b clang [-Wint-conversion]: Incompatible integer to
pointer conversion initializing 'Lisp_Object' (aka 'struct Lisp_X *') with an
expression of type 'int'
1573 21 warning e-f-b clang [-Wimplicit-function-declaration]: Implicit
declaration of function 'CHAR_TABLE_REF' is invalid in C99
I always assumed that this was becuase clangd didn't know how to compile
src/buffer.h and is unable to figure it out:
$ grep -F buffer.h compile_commands.json
<nothing printed>
After I run my emacs-fixup-compile-commands.py I have this in
compile_commands.json:
{
"arguments": [
"/usr/bin/gcc",
[...blah blah blah you get the point...]
"-Wno-unused-macros",
"-Wno-unused-function",
"-include",
"config.h",
"buffer.h"
],
"directory": "/home/matt/git/emacs-noverlay/src",
"file": "/home/matt/git/emacs-noverlay/src/buffer.h"
},
and clangd works fine.
Given all this I have no idea how your experience with clangd could
different, but I'm not a clangd expert 🤔.
> My current version is bear 3.0.20, on macOS 12.6. What's your system?
bear 3.0.20 on Debian/Bullseye (testing)
My issue may have been related to building with Address Sanitizer, which
I think also (might) play games with LD_PRELOAD. I tried
--force-wrapper and it worked for me. ;-)
> P.S.
>
> WRT to seamless, I have to add, for macOS: This was true for me with
> Xcode 13, and is no longer with Xcode 14. Both clangd and lldb crash
> pretty frequently :-(.
Maybe using the clangd from homebrew would work better for you?