pub enum Chip {
X86,
X64,
Arm,
Arm64,
}Expand description
The architectures Microsoft ships a CRT for, spelled the way each document spells them.
Two spellings, because the package ids and the SDK installer names disagree about case and
about arm64. That is not a thing to normalise away: both are keys into somebody else’s
document and a key is what it is.
Variants§
Implementations§
Source§impl Chip
impl Chip
Sourcepub const fn of(target: TargetTuple) -> Option<Self>
pub const fn of(target: TargetTuple) -> Option<Self>
Which chip a target is, or None for a target Microsoft ships nothing for.
ARM64EC has no answer here on purpose. It is tier 4 in
spec/cross-compile/04-target-matrix.md, nothing in this compiler emits code for it, and
the manifest’s ARM64EC packages are a few kilobytes of thunks rather than a C library.
Sourcepub const fn in_package(self) -> &'static str
pub const fn in_package(self) -> &'static str
How a Visual C++ package id spells it.
Sourcepub const fn in_installer(self) -> &'static str
pub const fn in_installer(self) -> &'static str
How a Windows SDK installer name spells it.
Sourcepub const fn in_tree(self) -> &'static str
pub const fn in_tree(self) -> &'static str
How the tree --sysroot reads spells it in a directory name.
LLVM’s names rather than Microsoft’s, because that is what xwin produces and the tree is
the one it produces. So a target that was fetched with xwin and one that was fetched with
this both answer to the same --sysroot, and the x64 in Microsoft’s own package names
stays in the packages where a person reading a manifest would go looking for it.