CC @belkadan & @aciidb0mb3r

@swift-ci create

The issue doesn't seem to be specific to inttypes.h. The toolchain path is listed earlier in the search paths, so it is preferred. For example, if I add a file myheader.h to the toolchain path and on the SDK path (along with adding module myheader ... in the SDK path's module.modulemap), the one in the toolchain path is preferred and produces the same error. Ben Langmuir pointed out that some of the toolchain headers use #include_next to include the SDK header (see clang docs to understand how that interacts with modules). The toolchain's inttypes.h does have a #include_next <inttypes.h> so that's not the issue, I think.

So the question is: what is special about float.h, stdint.h etc. that they do not produce this error? I think this has to do with the fact that they're builtins. To be more specific, if one looks at module.modulemap in the SDK, you'll see a bunch of modules such as float/stdint are builtins. None of the headers corresponding to non-builtin modules are also present in the toolchain path with the exception of inttypes.h.

As far as I can tell, this is a Clang issue, not a Swift issue. However, it would be good to understand why this is happening and provide a patch upstream or apply some workaround here.