Open BrknRules opened 1 week ago
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.
draculad - but I've notice the bug on whatever keyboard I open.
MacBook Air M2 macOS Sonoma 14.5
Ψ 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
None
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!
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.
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:
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.
Can I just confirm that removing all instances of the
__has_include
and__has_include_next
defines fromcompile_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
Did you restart the language server after regenerating the compile_commands.json
?
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 https://github.com/clangd/clangd/issues/1605
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.
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
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!
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.
Yikes, rolled back! thank you for the support on all of this, wild how much goes into some "simple" linting and syntax highlighting
Can I just confirm that removing all instances of the
__has_include
and__has_include_next
defines fromcompile_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 thedefault
draculad keymap just for a little more sanity.![]()
Updated 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.
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
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)