llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.8k stars 11.45k forks source link

Include cleaner not properly respecting "-nostdinc" #77452

Open FoxieFlakey opened 8 months ago

FoxieFlakey commented 8 months ago

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:

  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)
llvmbot commented 8 months ago

@llvm/issue-subscribers-clang-include-cleaner

Author: Foxie Flakey (FluffyFoxUwU)

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)