This makes no difference presently, but if LLVM ever starts modeling features
for these, we would not get them by default for our baseline if we use the
generic model.
This matches Clang's defaults. That also means these CPU models tend to get more
testing, so they're a safer baseline choice. Anecdotally, the oldest MIPS
hardware that I've seen anyone run Zig on was also r2.
ppc64le remains the baseline CPU model. Note that there's nothing about little
endian, 64-bit PowerPC that requires the features in the ppc64le model; the
reason it exists is that 64-bit PowerPC wasn't really used in little endian mode
prior to those features being commonplace. That makes the ppc64le model a good
baseline model, but not the right choice for a generic model.
```
std/os/uefi/protocol/simple_text_input.zig:10:63: error: no field named 'Win64' in enum '@typeInfo(builtin.CallingConvention).@"union".tag_type.?'
std/builtin.zig:169:31: note: enum declared here
std/os/uefi/protocol/simple_text_output.zig:9:64: error: no field named 'Win64' in enum '@typeInfo(builtin.CallingConvention).@"union".tag_type.?'
std/builtin.zig:169:31: note: enum declared here
std/os/uefi/tables/runtime_services.zig:26:86: error: no field named 'Win64' in enum '@typeInfo(builtin.CallingConvention).@"union".tag_type.?'
std/builtin.zig:169:31: note: enum declared here
```
using `.C` in Sema is incorrect since it will be resolved under the target that Zig was compiled with, not the target build configuration. This is easily solved by just calling `cCallingConvention` on the target to resolve it.
it doesn't detect and remove no longer watched things yet
it also isn't aware of any file names reported by kqueue. I'm unsure if
that functionality exists.
these tasks have some shared data dependencies so they cannot be done
simultaneously. Future work should untangle these data dependencies so
that more can be done in parallel.
for now this commit ensures correctness by making linker input parsing
and codegen tasks part of the same queue.
Unfortunately it's not a complete solution, so a follow-up commit will
need to do something more drastic like not do the linker task queue at
the same time as codegen task queue.
From that point, it is possible to do more work at the same time but
that should be a separate branch. This one has gotten big enough.
If the "is darwin" check is moved below the libc_installation check
below, error.LibCInstallationMissingCrtDir is returned from
lci.resolveCrtPaths().
This should be revisited because it makes sense to check
libc_installation first even on darwin.
Anyway for now this more closely matches logic from master branch.
By making it a field of link.Elf, it is now accessible without a data
dependency on `files`, fixing a race condition with the codegen thread
and linker thread.
