Add a GHA workflow to test our CMake build

[finagolfin]

Description

#1523 was recently merged, then broke the macOS trunk snapshot toolchain CI, because it was using macros that aren't there yet when building the toolchain, which had to be fixed in #1609.

This probably wasn't detected during PR testing because all the current PR CI jobs are using the macros from a prebuilt toolchain instead.

Reproduction

Do what the linked CI job does, ie build fresh macOS toolchain using macros as in #1523

Expected behavior

CI to catch such regressions

Environment

macOS

Additional information

It may be possible to set up a PR CI job with the prebuilt nightly snapshot toolchain and build-script, by passing in the prebuilt toolchain using the --skip-build-swift --native-swift-tools-path flags and building and installing this repo and its macros using that script alone, as the toolchain CI does in fuller form after a bunch of pulls are merged every day.

This would warn about such build errors before such pulls are merged.

[grynspan]

This was already resolved in #1609 (specifically for #_sourceLocation because that's the one that may crop up without being written explicitly.)

[finagolfin]

I think you misunderstand, this is about what I raised in that pull, ie adding CI so such mistakes don't happen again.

[stmontgomery]

@finagolfin The fix @grynspan made in #1609 actually will guard against this happening in the future because it includes some clever changes to the macro expansion which will detect when it's accidentally misused from a target where it shouldn't be. From the PR description:

Update the expansion of #_sourceLocation to detect it's being used in one of our own library targets and emit an error.

So although we didn't implement the precise change you suggested, we now have CI protection against this. (And we gain this protection without needing to switch to invoking build-script, which would take a lot longer to run!)

[finagolfin]

Correct me if I'm wrong, but looking at that pull, you simply add a warning so that #_sourceLocation is not invoked in the current debug builds in the CI jobs here.

Whereas what I'm suggesting is to set up a build-script CI job that will catch all such disallowed macro usage going forward, including other macros. Are you saying that is not a concern because #_sourceLocation is the only macro that might be misused that way, both now and in the foreseeable future?

we gain this protection without needing to switch to invoking build-script, which would take a lot longer to run!

Running build-script with a prebuilt nightly snapshot toolchain in the config I suggested would take minutes, the same amount of time as your current CI jobs.

[grynspan]

Correct me if I'm wrong, but looking at that pull, you simply add a warning so that #_sourceLocation is not invoked in the current debug builds in the CI jobs here.

The new diagnostic is an error and will cause every one of our current workflows to fail.

Are you saying that is not a concern because #_sourceLocation is the only macro that might be misused that way, both now and in the foreseeable future?

Yes, because #_sourceLocation is our only macro that can be used as a default argument accidentally. Any other macro usage will be visible on its face and I trust us to catch them during PR review.

If we muck it up again a different way, we can certainly revisit with the appropriate quantity of shame.

[finagolfin]

Yes, because #_sourceLocation is our only macro that can be used as a default argument accidentally. Any other macro usage will be visible on its face and I trust us to catch them during PR review.

OK, if you want a guarantee of that, I can set up a build-script CI job for you here that wouldn't run very long.