Bear generates invalid compile_commands.json with multiple entries from clang compilations

[damster101]

Describe the bug
When using Bear with clang, the generated compile_commands.json ends up containing two entries for a single compilation, one for the compiler driver and one for the frontend (-cc1), causing other software relying on compile_commands.json to fail. With gcc, only one correct entry is generated. And I'm pretty sure until recently this worked just fine with clang as well, so maybe something changed with recent clang versions?

To Reproduce
Create this file
hello-world.cpp

#include <print>

int main() {
  std::print("Hello, World!\n");
}

and compile with
bear -- clang++ -std=c++23 hello-world.cpp -o hello-world

Then look at the generated compile_commands.json.
I'm getting:

[
  {
    "arguments": [
      "/usr/bin/clang++",
      "-c",
      "-std=c++23",
      "-o",
      "hello-world",
      "hello-world.cpp"
    ],
    "directory": "/home/damian101/temp-cpp/Hello World",
    "file": "/home/damian101/temp-cpp/Hello World/hello-world.cpp",
    "output": "/home/damian101/temp-cpp/Hello World/hello-world"
  },
  {
    "arguments": [
      "/usr/bin/clang++",
      "-cc1",
      "-triple",
      "x86_64-pc-linux-gnu",
      "-emit-obj",
      "-dumpdir",
      "hello-world-",
      "-disable-free",
      "-clear-ast-before-backend",
      "-disable-llvm-verifier",
      "-discard-value-names",
      "-main-file-name",
      "-mrelocation-model",
      "pic",
      "-pic-level",
      "2",
      "-pic-is-pie",
      "-mframe-pointer=all",
      "-fmath-errno",
      "-ffp-contract=on",
      "-fno-rounding-math",
      "-mconstructor-aliases",
      "-funwind-tables=2",
      "-target-cpu",
      "x86-64",
      "-tune-cpu",
      "generic",
      "-debugger-tuning=gdb",
      "-fdebug-compilation-dir=/home/damian101/temp-cpp/Hello World",
      "-fcoverage-compilation-dir=/home/damian101/temp-cpp/Hello World",
      "-resource-dir",
      "/usr/lib/clang/20",
      "-internal-isystem",
      "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1",
      "-internal-isystem",
      "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1/x86_64-pc-linux-gnu",
      "-internal-isystem",
      "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../include/c++/15.1.1/backward",
      "-internal-isystem",
      "/usr/lib/clang/20/include",
      "-internal-isystem",
      "/usr/local/include",
      "-internal-isystem",
      "/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1/../../../../x86_64-pc-linux-gnu/include",
      "-internal-externc-isystem",
      "/include",
      "-internal-externc-isystem",
      "/usr/include",
      "-std=c++23",
      "-fdeprecated-macro",
      "-ferror-limit",
      "19",
      "-stack-protector",
      "2",
      "-fgnuc-version=4.2.1",
      "-fno-implicit-modules",
      "-fskip-odr-check-in-gmf",
      "-fcxx-exceptions",
      "-fexceptions",
      "-fcolor-diagnostics",
      "-faddrsig",
      "-D__GCC_HAVE_DWARF2_CFI_ASM=1",
      "-x",
      "c++",
      "-o",
      "/tmp/hello-world-bd186e.o",
      "hello-world.cpp"
    ],
    "directory": "/home/damian101/temp-cpp/Hello World",
    "file": "/home/damian101/temp-cpp/Hello World/hello-world.cpp",
    "output": "/tmp/hello-world-bd186e.o"
  }
]

Expected behavior
A compile_commands.json that looks like

[
  {
    "arguments": [
      "/usr/bin/g++",
      "-c",
      "-std=c++23",
      "-o",
      "hello-world",
      "hello-world.cpp"
    ],
    "directory": "/home/damian101/temp-cpp/Hello World",
    "file": "/home/damian101/temp-cpp/Hello World/hello-world.cpp",
    "output": "/home/damian101/temp-cpp/Hello World/hello-world"
  }
]

Environment:

• OS name: Arch Linux
• OS version: n/a
• OS architecture: x86_64
• Bear version: 3.1.6
• Bear install method: Pacman, from Arch Linux "extra" repository.

[rizsotto]

Hey @damster101 , yes this is a valid issue. Clang was always like this.

The new version I am working on will address this issue, by filtering entries by compiler flags.

I am not aware of a good workaround now. (Other than use g++ to generate the compilation database.)