fix: support header_contents() with clang_macro_fallback

[zRedShift]

Summary

Fixes #3351.

clang_macro_fallback() builds a fallback translation unit from the input headers. When the user only provides input through header_contents(), input_headers is empty, so fallback setup returns None and macros that need fallback evaluation are silently skipped.

Keep input_header_contents available to the generation context, materialize those virtual headers as temporary fallback headers while the PCH is alive, and include them in the fallback PCH setup.

The implicit --target fix from the original version of this PR was split out to #3382.

[emilio]

There's a bunch of other drive-by changes like where we put the `.macro_eval

View changes since this review

[emilio]

I'm confused, why is this needed? Is it intended to be some sort of path traversal escape prevention thing?

I'd rather avoid this, I don't think there's any use case for relative directories in header_contents(), tbh. In any case, this is just eating the FS errors etc, which seems bad. Let's either propagate it or crash?

[emilio]

I'd split the --target fix to a separate PR if possible.

[jgabaut]

Any news on this? I opened #3381 but I think I just had to update my dependency's binding generation to have explicit target arguments for mingw-w64.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[zRedShift]

Thanks, I split this up and rewrote this branch to be #3351-only.

The implicit --target fix is now #3382. For this PR, I removed the original path-preservation / path traversal handling and the broader tests around that behavior. The fallback now materializes generated scratch headers under the fallback build dir and panics on materialization write errors instead of silently swallowing them.