MCCAS wasn't setup correctly when using parallel WMO. Make sure the
CAS ObjectStore and ResultCallbacks are passed to LLVM backend when
using parallel WMO.
rdar://164409895
Specifically, we ignore the -Xllvm bit and put the option into
FrontendOptions.LLVMArgs so that parts of CompilerInvocation that assumes that
-Xllvm flags will be placed there are actually there. We still pass through the
argument to llvm::cl so it gets set that way as well.
With some changes that I am making, we will no longer need this flag at the SIL
level, so we can just make it an IRGen flag (which it really should have been
in the first place).
Specifically, I renamed the old llvm-as which printed with optimization as
llvm-as-opt and made llvm-as just test IRGen. That is really the true reason
that I created this utility many years ago: to test how IRGen lowers specific
SIL instruction sequences. How LLVM optimizes such sequences once lowered is a
different problem. I updated the one test that used sil-llvm-gen and required
optimizations to use llvm-as-opt so that the tests output did not change.
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
