emacs-devel
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]