Weird warning hint from the code browser - missing header guard when one present. It looks like some CMake based projects does not work well with KDevelop Clang based C/C++ language support. This is just one bug I noticed from many, which is however easy to reproduce, so I report it separately. * How to reproduce? * 1. Open attached SampleMultiProject. 2. In the project tree view click on the file ClassB.hpp (in SubProjectExecutable/include). 3. Put a mouse cursor to the first line of the file on the text "#pragma once" * What happens? * There is "warning/error" hint on the first line of the file in the editor (red underline) with following text "The given header is not guarded against multiple inclusions, either with the conventional #ifndef/#define/#endif macro guards or with #pragma once." * Expected behavior? * The correct use of language element should not be reported as warning/error. * Observations / Notes * - Please see attached video of the bug behavior. - Weird is that another file with similar contents do not show the bug - Even weirdest is that when I retype (cut&paste) the text "#pragma once" the problem disappears. - I did double check the CMake project for problems, but I did not find any which may cause this behavior.
Created attachment 109040 [details] How to reproduce bug - video
Created attachment 109041 [details] Sample project used to reproduce the issue.
Yes that warning is weird. I think it goes away if you actually have a cpp file which includes that header ...
Yes, you are right! Just tested right now. Ok, is this a bug? I still think that it is. I have more bugs like this, some more complex (e.g. After project is loaded everything is ok, when I do simple correct code change, it breaks and reports many warning/error hints). Is there any way how to get more debugging messages (e.g. how to enable extended debug messages or so)?
Bug still exists in kdevelop-5.4.3. When hovering, it gives the options: > Solution (1): Add #pragma once > Solution (2): Add macro-based #ifndef/#define/#endif header guard If I select option 1 and move the cursor away and then back, the dialog doesn't come back. If I select option 2, it adds the include guard but the dialog remains.
Created attachment 123895 [details] Reproduce clang parsing and test guarded
The bug still exists in recent version. I tried to get closer from its source and noticed that clang parsing wasn't detecting file guarded. So I reproduce the parsing in a simple project (this is the attached archive). In this project similar flags with kdevelop are used, and in this case CXTranslationUnit_CreatePreambleOnFirstParse flag is causing file to be not considered guarded, otherwise it is always guarded. I'm kind of lost with this argument, it seems to be an optimization, but I don't know if it's the expected behaviour of this flag… To execute the project : - build with cmake in a different directory - execute clangTest test.h ;see message "file guarded" or "file not guarded", you can comment flag in code.
After more investigation it seems that preamble is not taken into account by clang while it fetch for guarded macro. If the create preamble flag is disabled, a reparse of the unit will finally create it and the file is going again to be not considered guarded.
Yeah, this is annoying as all hell. (I'm using KDevelop 5.4.5 with gcc 9.) For example, when editing include/uapi/asm-generic/termb8its.h from Linux, the damn pop up appears anywhere I move my mouse, thus preventing me from clicking on what's behind it. A note here, it is guarded with: #ifndef __ASM_GENERIC_TERMBITS_H #define __ASM_GENERIC_TERMBITS_H ... #endif /* __ASM_GENERIC_TERMBITS_H */ and choosing Solution 2 adds: #ifndef TERMBITS_H_INCLUDED #define TERMBITS_H_INCLUDED ... #endif // TERMBITS_H_INCLUDED This is bad because this is a C file and // is not allowed in the kernel. Also, the code should not assume that it is not guarded if the macro used does BTW fit some specific format that is an arbitrary choice -- we should never push our personal coding standards or conventions on others. (FYI, yes I know that Linux is violating the C standard by using macros and other identifiers that start with _ or __.) In my case, I have set my C parser compiler to gcc and my command line args to this custom value (derived from the kernel make): -ferror-limit=100 -fspell-checking -Wdocumentation -Wunused-parameter -Wunreachable-code -Wall -nostdinc -isystem /home/daniel/proj/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/lib/gcc/mipsel-openwrt-linux-musl/7.3.0/include -I/home/daniel/proj/kernel/4.14/arch/mips/include -I/home/daniel/proj/kernel/4.14/arch/mips/include/generated -I/home/daniel/proj/kernel/4.14/include -I/home/daniel/proj/kernel/4.14/arch/mips/include/uapi -I/home/daniel/proj/kernel/4.14/arch/mips/include/generated/uapi -I/home/daniel/proj/kernel/4.14/include/uapi -I/home/daniel/proj/kernel/4.14/include/generated/uapi -include /home/daniel/proj/kernel/4.14/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80000000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -m32 -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -fno-pic -pipe -msoft-float -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float -ffreestanding -fno-stack-check -march=i386 -Wa,--trap -DTOOLCHAIN_SUPPORTS_VIRT -I/home/daniel/proj/kernel/4.14/arch/mips/include/asm/mach-ralink -I/home/daniel/proj/kernel/4.14/arch/mips/include/asm/mach-ralink/mt7620 -I/home/daniel/proj/kernel/4.14/arch/mips/include/asm/mach-generic -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fverbose-asm -S Thank you! PS: Yes, I'm lying to gcc and having it parse the mipsel architecture, but only for code formatting since there's not a way to specify the actual gcc compiler used for parsing. So I'm telling it the arch is i386 to get it to use 32-bit ints and pointers.
For what it’s worth, I seem to be able to trigger this bug when includes have two files with same file name. Specifically, when I was inspecting a kernel module, there is multiple acpi.h files in kernel sources. For example <linux/acpi.h> includes <acpi/acpi.h>. The latter include gets this warning, and parsing of that file is refused. First file is parsed correctly as far as I understand it.