use cargo rustc for macro expansion so -Zbuild-std can be supported

[skrap]

Description

Address #5204 by invoking macro expansion through cargo rustc instead of rustc directly. This allows the use of the -Zbuild-std flag, enabling targets without a prebuilt std (e.g. tier 3 targets) to build the libc tests.

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[tgross35]

Cc @mbyx for ctest

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[skrap]

@rustbot review

I think I have addressed the feedback, though in exploring the changes I sometimes made some different choices. I've left comments in the conversations where appropriate.

[skrap]

@rustbot review

Further review feedback. I'm a bit shy about adding more API than necessary for the stated purpose of the PR. If we have a clear use case for the API proposed, I think that should be proposed in a separate PR.

[tgross35]

Just updating the status here.

Also, regarding the general concern about API surface area: don't worry about it :) as long as it's somewhat sane, for ctest I tend to err on the side of adding small things we might need while related code is already being modified, rather than leaving a gap that might need ctest-specific changes in the future. There might be somebody who appreciates it even if libc doesn't have an immediate use.

View changes since this review

[skrap]

@rustbot review

OK, I have gone with your suggestions on the remaining items. Please have a look. I will squash the commits into one before merging.

[tgross35]

Last pass, noticed a few small things then happy to merge

View changes since this review

[skrap]

@rustbot review

Applied the small changes requested and squashed the PR to a single commit.

[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.