hedronvision / bazel-compile-commands-extractor

Goal: Enable awesome tooling for Bazel users of the C language family.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug, Wrong C++ standard flag passed in to compile_commands.json when standard is specified in .bazelrc

janeusz2000 opened this issue · comments

Hey,

I've bumped into a case where the c++ standard flag is not correctly passed into compile_commands.json file.
My .bazelrc looks like:

test --test_output=errors
build -c opt --cxxopt='-std=c++17'

and after command execution:
bazel run @hedron_compile_commands//:refresh_all
i get:

 .
 .
 .
 {
    "file": "external/bazel_tools/src/tools/launcher/dummy.cc",
    "arguments": [
      "/usr/bin/gcc",
      "-xc++",
      "-U_FORTIFY_SOURCE",
      "-fstack-protector",
      "-Wall",
      "-Wunused-but-set-parameter",
      "-Wno-free-nonheap-object",
      "-fno-omit-frame-pointer",
      "-g0",
      "-O2",
      "-D_FORTIFY_SOURCE=1",
      "-DNDEBUG",
      "-ffunction-sections",
      "-fdata-sections",
      "-std=c++0x",                                 # <- this is where flag is wrong
      "-MD",
      "-MF",
      "bazel-out/host/bin/external/bazel_tools/src/tools/launcher/_objs/launcher/dummy.d",
      "-frandom-seed=bazel-out/host/bin/external/bazel_tools/src/tools/launcher/_objs/launcher/dummy.o",
      "-iquote",
      "external/bazel_tools",
      "-iquote",
      "bazel-out/host/bin/external/bazel_tools",
      "-g0",
      "-g0",
      "-Wno-builtin-macro-redefined",
      "-D__DATE__=\"redacted\"",
      "-D__TIMESTAMP__=\"redacted\"",
      "-D__TIME__=\"redacted\"",
      "-c",
      "external/bazel_tools/src/tools/launcher/dummy.cc",
      "-o",
      "bazel-out/host/bin/external/bazel_tools/src/tools/launcher/_objs/launcher/dummy.o"
    ],
    "directory": "/home/animator/rayTradingInAcoustics"
    .
    .
    .

Let me know if you need some additional info ;)

Hey, @janeusz2000! Thanks for giving the tool a go and for writing in :)

Are you seeing the missing flags for commands elsewhere besides dummy.cc?

At least in my test projects, dummy.cc (a strange, special Bazel internal thing) lacks the flag, but all my real files have the flags right.

Cheers!
Chris

hey,

I made some research and I found that there are more C++11 flags passed around:

  },
  {
    "file": "/usr/include/c++/11/climits",
    "arguments": [
      "/usr/bin/gcc",
      "-xc++",
      "-U_FORTIFY_SOURCE",
      "-fstack-protector",
      "-Wall",
      "-Wunused-but-set-parameter",
      "-Wno-free-nonheap-object",
      "-fno-omit-frame-pointer",
      "-g0",
      "-O2",
      "-D_FORTIFY_SOURCE=1",
      "-DNDEBUG",
      "-ffunction-sections",
      "-fdata-sections",
      "-std=c++0x",
      "-MD",
      "-MF",
      "bazel-out/k8-opt/bin/external/com_google_googletest/_objs/gtest/gtest-filepath.d",
      "-frandom-seed=bazel-out/k8-opt/bin/external/com_google_googletest/_objs/gtest/gtest-filepath.o",
      "-iquote",
      "external/com_google_googletest",
      "-iquote",
      "bazel-out/k8-opt/bin/external/com_google_googletest",
      "-isystem",
      "external/com_google_googletest/googlemock",
      "-isystem",
      "bazel-out/k8-opt/bin/external/com_google_googletest/googlemock",
      "-isystem",
      "external/com_google_googletest/googlemock/include",
      "-isystem",
      "bazel-out/k8-opt/bin/external/com_google_googletest/googlemock/include",
      "-isystem",
      "external/com_google_googletest/googletest",
      "-isystem",
      "bazel-out/k8-opt/bin/external/com_google_googletest/googletest",
      "-isystem",
      "external/com_google_googletest/googletest/include",
      "-isystem",
      "bazel-out/k8-opt/bin/external/com_google_googletest/googletest/include",
      "-std=c++17",
      "-pthread",
      "-Wno-builtin-macro-redefined",
      "-D__DATE__=\"redacted\"",
      "-D__TIMESTAMP__=\"redacted\"",
      "-D__TIME__=\"redacted\"",
      "-c",
      "external/com_google_googletest/googletest/src/gtest-filepath.cc",
      "-o",
      "bazel-out/k8-opt/bin/external/com_google_googletest/_objs/gtest/gtest-filepath.o"
    ],
    "directory": "/home/animator/rayTradingInAcoustics"
  },

This is STL and I am not sure if its the issue of the Bazel itself or a designed feature :P [I don't have a folder /usr/include/c++/17 even tho I use a lot of C++ features and my code can compile].
My issue is that I try to integrate Clangd with my Neovim setup and if I search and replace compile_commands.json: -std=c++0x with '-std=c++17' static analysis start to work smoothly.... This could be the case that Bazel tries to be super accurate or something weird is going on. IMO If I compile code in c++17, everything should be set to c++17.

cheers :)
Mathew

EDIT: I see that c++ standard flag was given twice here for some reason and that could be the case why I have this problem

Hey, Matthew! Thanks for writing back.

I'm bummed this isn't working. I'd have expected it to! Happy to dig in more together.

For context: That's exactly the command Bazel's running. Bazel has a default -std flag from the toolchain (0x on your machine), and then appends the cxxopt you added. Supplying the -std=c++17 after should override the default, as it does when you compile.

So that's the command I'd have expected to see, and it should specify C++17 via override, as it does when you bazel build.

But there are two very unexpected things here:

  1. /usr/include/c++/17 not existing.
    That's really surprising, because we (this tool) are getting that file's path by invoking gcc and asking which headers it wants to include. And it's saying "yeah, I import climits from there". Plus, that looks reasonable.
    You're sure? Do you know what path at which you'd expect it to find the standard library/climits normally?
  2. Replacing -std=c++0x with -std=c++17 changes/fixes things.
    The latter option should override, so it's really surprising that this changes anything. If so, that'd be a clangd bug, since that's not how gcc or clang would parse those flags. If that issue exists, we should file it over at clangd/cland and manually patch that case here in the meantime...but I know I've tested this particular case a bunch on my machine and seen it work. Any chance you could share more info about what error occurs that this resolves? Anything interesting in the clangd logs? It might be especially interesting to see what it logs for the default include paths from --query-driver. These lines include prefixes like "system includes".

Cheers,
Chris

Hey, Matthew. Bumping because I'm going to need more of your help to fix, since I haven't been able to reproduce this issue yet.

Hey, Matthew. Bumping because I'm going to need more of your help to fix, since I haven't been able to reproduce this issue yet.

What additional info do you need? I can bump My whole compile_commands.json file: compile_commands.json

This is the repository that I am generating compile commands: RayTracingWithAcoustics

system info:
Ubuntu 22.04.1 LTS

clang:
Ubuntu clang version 14.0.0-1ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

clangd:
Ubuntu clangd version 14.0.0-1ubuntu1
Features: linux+grpc
Platform: x86_64-pc-linux-gnu

content of /usr/include/c++:

animator@AnimXPS /u/include> cd c++
animator@AnimXPS /u/i/c++> ll
total 16K
drwxr-xr-x 12 root root 4.0K Sep 11 14:50 11/
drwxr-xr-x 13 root root  12K Sep 11 14:51 9/

Let me know if you need anything more. If you want some urgent info you can email me at: mateusz.krzysztof.janik@gmail.com... I am not using github at work so I don't go very often here.

I will give you clang d logs here after I will finish work for today :)

I dont know why, but rerender of the compile commands fixed the issue that I had... so I don't know where the problem was ;( ... maybe If I bump into the same issue again, I will reopen again with some additional info. I am not getting any errors in the clangd logs again. Thanks for attention and help :).

PS. I am fetching the newest master/main version of this repo, so maybe it was fixed along the way :)

Hey, @janeusz2000! Glad to hear things are working--and I appreciate your writing in. If it does come back, please do let me know. I'd love to squash whatever underlying issue this was (if it hasn't been already) so that it doesn't bother you or anyone else.

Happy trails!