My environment is my own kernel development and naturally would includes -nostdinc -isystem <src dir> in C flags. I have Diagnostics.MissingInclude = Strict and also use -isystem due my preference to use <header> in kernel developments.
I typedef'ed equivalent C's fixed types (like uint32_t, uint64_t, etc) in different header file name as those C's fixed types doesn't exist in -nostdinc mode.
When I opened this main.c. Clangd's include cleaner was suggesting to "fix" by including <stdint.h> when obviously I already included my own types.h and stdint.h doesn't exist.
The expectation: Include cleaner to not suggest any fix
The reality: Include cleaner suggest wrong fix when clearly types.h provides it and stdint.h doesn't exist
Reproducible sample:
types.h
#pragma once
typedef unsigned int uint32_t;
main.c
#include <types.h>
// No header providing "uint32_t" is directly included (fix available)
// (clangd missing-includes)
static uint32_t userOfUint32;
Clangd Version: 17.0.6
Additional note I found during writing of the sample:
When I used "types.h" instead <types.h>, include cleaner wrongly mark it as unused
Also happen if I used identifier from C standard (like uint32_t, fopen, fflush, errno, etc) caused the same "fix" suggestion but from respective header (like errno suggests errno.h header)
It doesn't happen if I use non C standard's identifiers (I have tried use "ffi_call" from libffi's "ffi.h" but no fix was suggested)
My environment is my own kernel development and naturally would includes `-nostdinc -isystem <src dir>` in C flags. I have `Diagnostics.MissingInclude = Strict` and also use `-isystem` due my preference to use `<header>` in kernel developments.
I typedef'ed equivalent C's fixed types (like `uint32_t`, `uint64_t`, etc) in different header file name as those C's fixed types doesn't exist in `-nostdinc` mode.
When I opened this `main.c`. Clangd's include cleaner was suggesting to "fix" by including `<stdint.h>` when obviously I already included my own `types.h` and `stdint.h` doesn't exist.
The expectation: Include cleaner to not suggest any fix
The reality: Include cleaner suggest wrong fix when clearly `types.h` provides it and `stdint.h` doesn't exist
Reproducible sample:
types.h
```c
#pragma once
typedef unsigned int uint32_t;
```
main.c
```c
#include <types.h>
// No header providing "uint32_t" is directly included (fix available)
// (clangd missing-includes)
static uint32_t userOfUint32;
```
Clangd Version: 17.0.6
Additional note I found during writing of the sample:
1. When I used `"types.h"` instead `<types.h>`, include cleaner wrongly mark it as unused
2. Also happen if I used identifier from C standard (like `uint32_t`, `fopen`, `fflush`, `errno`, etc) caused the same "fix" suggestion but from respective header (like `errno` suggests `errno.h` header)
3. It doesn't happen if I use non C standard's identifiers (I have tried use "ffi_call" from libffi's "ffi.h" but no fix was suggested)
My environment is my own kernel development and naturally would includes
-nostdinc -isystem <src dir>
in C flags. I haveDiagnostics.MissingInclude = Strict
and also use-isystem
due my preference to use<header>
in kernel developments.I typedef'ed equivalent C's fixed types (like
uint32_t
,uint64_t
, etc) in different header file name as those C's fixed types doesn't exist in-nostdinc
mode.When I opened this
main.c
. Clangd's include cleaner was suggesting to "fix" by including<stdint.h>
when obviously I already included my owntypes.h
andstdint.h
doesn't exist.The expectation: Include cleaner to not suggest any fix The reality: Include cleaner suggest wrong fix when clearly
types.h
provides it andstdint.h
doesn't existReproducible sample:
types.h
main.c
Clangd Version: 17.0.6
Additional note I found during writing of the sample:
"types.h"
instead<types.h>
, include cleaner wrongly mark it as unuseduint32_t
,fopen
,fflush
,errno
, etc) caused the same "fix" suggestion but from respective header (likeerrno
suggestserrno.h
header)