in favor of CPU features. Also rearrange the `std.Target`
data structure.
* note: `@import("builtin")` was already deprecated in favor of
`@import("std").builtin`.
* `std.builtin.arch` is now deprecated in favor of
`std.builtin.cpu.arch`.
* `std.Target.CpuFeatures.Cpu` is now `std.Target.Cpu.Model`.
* `std.Target.CpuFeatures` is now `std.Target.Cpu`.
* `std.Target` no longer has an `arch` field. Instead it has a
`cpu` field, which has `arch`, `model`, and `features`.
* `std.Target` no longer has a `cpu_features` field.
* `std.Target.Arch` is moved to `std.Target.Cpu.Arch` and
it is an enum instead of a tagged union.
* `std.Target.parseOs` is moved to `std.Target.Os.parse`.
* `std.Target.parseAbi` is moved to `std.Target.Abi.parse`.
* `std.Target.parseArchSub` is only for arch now and moved
to `std.Target.Cpu.Arch.parse`.
* `std.Target.parse` is improved to accept CPU name and features.
* `std.Target.Arch.getBaselineCpuFeatures` is moved to
`std.Target.Cpu.baseline`.
* `std.Target.allCpus` is renamed to `std.Target.allCpuModels`.
* `std.Target.defaultAbi` is moved to `std.Target.Abi.default`.
* Significant cleanup of aarch64 and arm CPU features, resulting in
the needed bit count for cpu feature set going from 174 to 138.
* Add `std.Target.Cpu.Feature.Set.addFeatureSet` for merging
feature sets together.
`-target-feature` and `-target-cpu` are removed in favor of
`-mcpu`, to conform to established conventions, and it gains
additional power to support cpu features. The syntax is:
-mcpu=name+on1+on2-off1-off2
closes#4261
- split util_base.hpp from util.hpp
- new namespaces: `mem` and `heap`
- new `mem::Allocator` interface
- new `heap::CAllocator` impl with global `heap::c_allocator`
- new `heap::ArenaAllocator` impl
- new `mem::TypeInfo` extracts names without RTTI
- name extraction is enabled w/ ZIG_ENABLE_MEM_PROFILE=1
- new `mem::List` takes explicit `Allocator&` parameter
- new `mem::HashMap` takes explicit `Allocator&` parameter
- add Codegen.pass1_arena and use for all `ZigValue` allocs
- deinit Codegen.pass1_arena early in `zig_llvm_emit_output()`
The new plan to support hobby operating systems is #3784.
And what kind of name is "Zen" anyway? There's already a
[Zen programming language](http://zenlang.sourceforge.net/)
and that's just confusing.
Clang does not support -march=native for all targets.
Arguably it should always work, but in reality it gives:
error: the clang compiler does not support '-march=native'
If we move CPU detection logic into Zig itelf, we will not need this,
instead we will always pass target features and CPU configuration explicitly.
For now, we simply avoid passing the flag when it is known to not be
supported.
This reverts commit ec7d7a5b14540ea3b2bab9f11318630338467965, reversing
changes made to 81c441f8855d4c58f0b2ff86d3d007cf0bf395d3.
It looks like this broke colors in Windows Command Prompt (#3147)
and this method of detecting native C ABI isn't working well (#3121).
Zig provides a libc for the GNU C ABI on Windows, and cannot (at least
yet) provide one for the MSVC C ABI. However when not linking libc,
zig has no problem targeting MSVC as the C ABI. And this should be the
default.
Related: #2911
* fixed --verbose-cc printing an extra "zig" before the rest of
the command line
* windows-gnu targets use libfoo.a, foo.o extensions to match mingw
conventions.
windows.h has files such as pshpack1.h which do #pragma packing,
triggering a clang warning. So for this target, this warning is
disabled.
this commit also improves the error message printed when no libc can be
used, printing the "zig triple" rather than the "llvm triple".
Fixes glibc_version being set to garbage. I've made this mistake
before so this is an attempt to prevent future bugs. Zig doesn't
have zero-initialization, so are we being a hypocrite by using this
C feature? No, because C doesn't have the feature that forces you to
initialize all fields. That would have prevented this bug every single
time.
