Wrong system header included

[FaBrand]

I discovered that because of the hardwired includes here:

https://github.com/hexdae/toolchains_arm_gnu/blob/v1.1.0/toolchain/templates/compiler.BUILD#L24-L33

    srcs = [
      "{}/include/c++/{}".format(PREFIX, VERSION),
      "{}/include/c++/{}/{}".format(PREFIX, VERSION, PREFIX),
      "{}/include".format(PREFIX),
      "lib/gcc/{}/{}/include".format(PREFIX, VERSION),
      "lib/gcc/{}/{}/include-fixed".format(PREFIX, VERSION),
    ],

General issue

If a c++ header has the same name as a c header and when compiling a C file, the wrong header is picked in that order.

e.g. stdatomic

find . -name stdatomic.h
./arm-none-eabi/include/c++/13.2.1/stdatomic.h
./arm-none-eabi/include/stdatomic.h

Considerations

With -nostdinc the compiler is not searching/deciding by itself anymore.
When disabled, i think it makes sense to not pass the system include paths "manually"

Aka something like this:

--- a/toolchain/config.bzl
+++ b/toolchain/config.bzl
@@ -32,6 +33,7 @@ def _default_compiler_flags(ctx):
     ]

     if not ctx.attr.include_std:
+        compiler_flags.extend(["-I" + include.path for include in ctx.files.include_path])
         compiler_flags.append("-nostdinc")
         if ctx.attr.gcc_tool == "g++":
             compiler_flags.append("-nostdinc++")
@@ -102,7 +103,6 @@ def _impl(ctx):
                     ACTION_NAMES.clif_match,
                 ],
                 flag_groups = [
-                    flag_group(flags = ["-I" + include.path for include in ctx.files.include_path]),
                     flag_group(flags = ctx.attr.copts + default_compiler_flags),
                 ],
             ),

Alternatively, it could only be passed to c/c++ compile actions respectively using the cpp action names.

Or drop the manual includes alltogether and let the compiler decide via sysroot and nostdinc

[FaBrand]

Currently primarily wrote this to get your feedback @hexdae
Once the way forward is clear, we can think about the implementation

[hexdae]

Yeah this is somewhat confusing. My preference would be to use the C++ actions.

this should mirror what g++ does under the hood.