[ASTGen] Avoid including C standard libary headers in brigdging headers

[rintaro]

Instead, use builtin types. e.g. size_t -> unsigned long

C stdlib headers are part of Darwin/Glibc clang module. If a Swift file imports a bridging headers and that has #include C stdlib headers, Swift compiler implicitly imports Darwin/Glibc overlay modules. That violates dependency layering. I.e. Compiler depends on Darwin overlay, Darwin overlay is created by the compiler.

rdar://107957117

[rintaro]

@swift-ci Please smoke test

[rintaro]

@swift-ci Please smoke test

[bnbarham]

This is ... unfortunate but I have no better workarounds. Any thoughts @etcwilde @compnerd?

[compnerd]

No, sadly, there is no good solution here that I can think of. We do have SwiftShims that can provide some of these, particularly the sized types, which is exactly for this reason.

[compnerd]

C:\Users\swift-ci\jenkins\workspace\swift-PR-windows\swift\lib\AST\CASTBridging.cpp(693): error C2397: conversion from 'unsigned __int64' to 'unsigned long' requires a narrowing conversion

Seems that there are some width issues here

[rintaro]

@swift-ci Please smoke test

[etcwilde]

huh, not having C headers is most unfortunate. Once we require a Swift compiler in the builder toolchain, we should be able to go back since we can use that Swift to generate the modules needed to build the compiler, no?

Alternatively, could we use the appropriate C++ headers instead? e.g #include <cstdint> or does that trigger the same issue?

[rintaro]

@swift-ci Please smoke test

[rintaro]

Alternatively, could we use the appropriate C++ headers instead? e.g #include or does that trigger the same issue?

Maybe 🤔? But since this is imported from Swift code built with host Swift compilers, I don't think we can use any C++ headers in these at this point