Drop the -fundamental suffix from src/fundamental/ headers in favor of names
that match their src/basic/ or src/shared/ counterparts (e.g.
macro-fundamental.h -> macro.h, assert-fundamental.h -> assert-util.h,
cleanup-fundamental.h -> cleanup-util.h). Rename src/basic/{btrfs,label}.{c,h}
to use the -util suffix to match the existing shared/btrfs-util and
shared/label-util siblings. Rename src/shared/mkdir-label.{c,h} to mkdir.{c,h}
and src/shared/tmpfile-util-label.{c,h} to tmpfile-util.{c,h} to match the
corresponding src/basic names.
This saves us from having to come up with separate names for files that do
the same thing across tiers, and it makes it easier to move stuff between
src/fundamental, src/basic and src/shared: consumers just #include "foo.h"
and pick up whichever tier their -I path resolves to first, so call sites
don't need to be updated when an API moves between layers.
Where a higher-tier wrapper exists (e.g. src/basic/macro.h wrapping
src/fundamental/macro.h), the wrapper uses an explicit "../fundamental/foo.h"
or "../basic/foo.h" relative include for the lower-tier header. We can't use
GCC's #include_next directive for this — when the wrapper is reachable both
via same-dir-as-source lookup and via -I (e.g. -Isrc/shared) for the
directory it lives in, #include_next advances by exactly one slot in libcpp's
internal directory chain and lands on the same physical directory it was
already in, never reaching the lower-tier sibling (see make_cpp_dir() in
gcc/libcpp/files.cc:1986).
To make sure the right headers are always picked up, the include directories
are reordered so that e.g. src/shared always takes priority over src/basic and
similar for the other directories.
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Several GCC-only options in our compile_commands.json
(-fwide-exec-charset=UCS2, used by EFI boot code for UTF-16 string
literals, and -maccumulate-outgoing-args) cause clangd to emit
driver-level "unknown argument" errors. These can't be silenced through
Diagnostics.Suppress, so remove them via CompileFlags.Remove before
clang ever sees them.
Also suppress the -Wunknown-attributes warning that fires on every use
of _no_reorder_, since meson unconditionally expands it to the GCC-only
__no_reorder__ attribute when configured with GCC.
Now that the entire free doesn't trigger any clang unused include
violations anymore, let's re-enable the clangd option as it's much
more useful now that the tree is clean.
The clangd include checker is rather broken and is littered with false
positives in our codebase, so let's disable the feature until it improves
a bit.
Daan De Meyer
Daan De Meyer