[Bug] compile_commands.json breaks VSCode clangd intellisense by defining non-existent macros

[BrknRules]

Describe the Bug

compile_commands.json includes the following macro definitions:
-D __has_include(STR)=__has_include__(STR) and -D __has_include_next(STR)=__has_include_next__(STR)

This causes clangd to break VSCode's intellisense, emitting macro not defined errors.

Removing these flags from the compile_commands.json ended up fixing the issue for me.

Keyboard Used

keebio/quefrency/rev4

Link to product page (if applicable)

https://keeb.io/products/quefrency-rev-4-65-split-staggered-keyboard?_pos=13&_sid=e65f328e4&_ss=r

Operating System

MacBook Pro M1 Pro macOS Sonoma 14.5

qmk doctor Output

No response

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

QMK Toolbox

Additional Context

qmk compile --compiledb -kb keebio/quefrency/rev4 -km default was run first.
clangd version = 18.1.3 (VSCode clangd extension latest install)

[willhack]

Same issue here. Compiling and flashing run flawlessly, there seems to be something odd with the linter/LSP.

For sanity I tried a fresh install of VSCode as well, making sure to blow out any existing settings and just following the QMK guides to the letter.

Keyboard Used

draculad - but I've notice the bug on whatever keyboard I open.

Operating System

MacBook Air M2 macOS Sonoma 14.5

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.5
Ψ QMK home: /Users/will/repos/qmk_firmware
Ψ Detected macOS 14.5 (Intel).
Ψ Userspace enabled: False
Ψ Git branch: willhack
Ψ Repo version: 0.24.7
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest willhack: 2024-06-28 00:01:49 -0400 (a2dac72f4a) -- auto-migrate
Ψ - Latest upstream/master: 2024-06-27 13:37:41 -0400 (9d02ac37f7) -- Add Nyquist Rev. 5 (#23971)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2024-06-27 13:37:41 -0400 (9d02ac37f7) -- Add Nyquist Rev. 5 (#23971)
Ψ - Common ancestor with upstream/develop: None
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.5.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.3
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
 ....
Ψ QMK is ready to go, but minor problems were found

Other keyboard-related software installed

None

Additional Context

Also ran qmk generate-compilation-database resulting in:

Ψ Gathering build instructions from gmake -r -R -f builddefs/build_keyboard.mk -s -n KEYBOARD=draculad KEYMAP=gotham KEYBOARD_FILESAFE=draculad TARGET=draculad_gotham INTERMEDIATE_OUTPUT=.build/obj_draculad_gotham VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"

Screenshot showing various error messages resulting.

---

qmk lint goes off without a hitch
Ψ Lint check passed!

compile_commands.json

[tzarc]

There's obviously something going on with the compiler here; if I do qmk compile --compiledb -kb draculad -km default, I don't get anything with -D __has_include(STR)=__has_include__(STR) nor -D __has_include_next(STR)=__has_include_next__(STR) inside compile_commands.json.

Note that clang is not a participant at the point where compile_commands.json is generated -- that's a combination of parsing the make output and inferring values from the defaults supplied by the compiler by preprocessing an empty file with the compiler arguments set up to build for the target architecture.

I think the best we can do is to blacklist such entries.

[tzarc]

Can I just confirm that removing all instances of the __has_include and __has_include_next defines from compile_commands.json actually fixes things?

My local environment doesn't export them, and I correctly get the following:

[tzarc]

Yeah looks like it's an old compiler issue -- if I reissue the same command within the ghcr.io/qmk/qmk_cli:latest container (with gcc 8.x) then I get the same output in compile_commands.json as well as the deficient loading within VScode.

Will see if we can mitigate the old compiler issue rather than enforcing a higher version.

[willhack]

Can I just confirm that removing all instances of the __has_include and __has_include_next defines from compile_commands.json actually fixes things?

Not sure if this solves OPs issues, but I'm still seeing erroneous linting errors. I've manually removed all instances of -D __has_include(STR)=__has_include__(STR) and -D __has_include_next(STR)=__has_include_next__(STR). Also switched to testing on the default draculad keymap just for a little more sanity.

Updated compile_commands.json

[tzarc]

Did you restart the language server after regenerating the compile_commands.json?

[willhack]

Yep! Even blew out the .cache and restarted VSCode. That being said in the clangd output I see the following:

E[22:26:40.434] IncludeCleaner: Failed to get an entry for resolved path : No such file or directory
...
I[22:26:40.449] Indexed c17 standard library (incomplete due to errors): 2506 symbols, 24 filtered

Could that IncludeCleaner have something to do with it? Not sure how to debug what resolved path it's looking for

Edit: Grasping at straws, but I see a possibly related issue to do with cross compilation and query-driver issues clangd/clangd#1605

[tzarc]

Honestly not sure; I've been using gcc 14 for a while and don't strike any of these issues. I'll try and replicate on an older system later today.

[tzarc]

If you've got some familiarity with setting up things on your $PATH, you could try the same toolchain and see if it helps:
https://github.com/qmk/qmk_toolchains/releases/tag/v14.1.0-3

[willhack]

If you've got some familiarity with setting up things on your $PATH, you could try the same toolchain and see if it helps: https://github.com/qmk/qmk_toolchains/releases/tag/v14.1.0-3

Not entirely sure how to switch the toolchain via the path.
Just did quite a bit of googling and switched from apple clang to the brew/gnu versions of gcc and g++ ---

❯ gcc --version
gcc-14 (Homebrew GCC 14.1.0_1) 14.1.0

but I'm still seeing the errors and compile_commands.json hasn't changed.

Not entirely sure where to poke around at next, but happy to keep trying things!

[tzarc]

Not entirely sure how to switch the toolchain via the path. Just did quite a bit of googling and switched from apple clang to the brew/gnu versions of gcc and g++

I’d suggest rolling this back — you’ve changed the compiler targeting your MacBook — I was suggesting changing the compiler targeting the chip for QMK. Two completely different beasts.

For now I’d hold off on making any more changes (after rolling back above); I’m seeing if I can do something with toolchain management baked into the QMK CLI itself.

[willhack]

Yikes, rolled back! thank you for the support on all of this, wild how much goes into some "simple" linting and syntax highlighting

[BrknRules]

Can I just confirm that removing all instances of the __has_include and __has_include_next defines from compile_commands.json actually fixes things?

Not sure if this solves OPs issues, but I'm still seeing erroneous linting errors. I've manually removed all instances of -D __has_include(STR)=__has_include__(STR) and -D __has_include_next(STR)=__has_include_next__(STR). Also switched to testing on the default draculad keymap just for a little more sanity.

Updated [compile_commands.json](https://github.com/user-attachments/files/16047294/compile_commands.json)

I only removed these specific flags because VSCode was throwing macro not defined errors after I drilled down and tried to find the type definitions in the codebase. If what @tzarc says is true, our problem may be a symptom of the compiler inferring differing values from the defaults based on some difference between our machines.

Maybe find which header files your types are defined in and checking if they're included in compile_commands.json correctly? As a temporary fix.