Dave Abrahams

Any alternative is fine with me. The use of dependent jobs wasn't really supposed to be a part of the goal, even if it was phrased that way.

Also it would be good to evaluate our existing cache steps to see if they are providing any value.

@WalterSmuts IIRC you found that caches were a net loss, and [this](https://github.com/KyleMayes/install-llvm-action/commit/878985d084d4991346a5f6f26eae447ddc16457a) seems to confirm that.

> have a chat Yes, lets! >> That kind of documentation is actively harmful. > > I don't want to be that categoric. You do realize I'm just talking about...

You might consider whether a solution like [this](https://github.com/hylo-lang/hylo/blob/main/Sources/IR/FullPathInFatalErrors.swift) can work. This file should be hoisted to a central place (like a root level `SharedSource` directory) and symlinked into the many...

If we write differently-named functions as you've proposed, they can go in a library, but they should follow naming conventions. The word "assert" is badly overloaded here; I suggest we...

The only downside with the library is that you need to exercise discipline to _not_ use `XCTAssert` et. al. directly. As a QOI matter you might look into adding overloads...

If we're going to use our own names, "assert" is the wrong string to use for checks. Function names should follow standard Swift naming conventions (start with a lowercase letter)...

If you use symlinks, you can follow the pattern of #1308

We have no specific plans for that yet, but that may be because PGO has no champion among the project contributors; we'd certainly be interested in having PGO support if...