`{}` for decls
`{p}` for enum fields
`{p_}` for struct fields and in contexts following a `.`
Elsewhere, `{p}` was used since it's equivalent to the old behavior.
Justification: exec, execv etc are unix concepts and portable version
should be called differently.
Do no touch non-Zig code. Adjust error names as well, if associated.
Closes#5853.
* some manual fixes to generated CPU features code. in the future it
would be nice to make the script do those automatically. I suspect
the sm_90a thing is a bug in LLVM.
* add liteos to various target OS switches. I know nothing about this
OS; someone will need to work specifically on support for this OS
when the time comes to support it properly in zig.
* while waiting for the compiler, I went ahead and made more
conservative choices about when to use `inline` in std/Target.zig
Commit 40f5e5dfc6 ("CLI: introduce -fsingle-threaded/
-fno-single-threaded", 2021-12-01) removed the `--single-threaded`
option, but didn't update all mentions of it.
$ zig version
0.11.0-dev.1568+c9b957c93
$ zig build-exe --help | grep single
-fsingle-threaded Code assumes there is only one thread
-fno-single-threaded Code may not assume there is only one thread
$ zig build-exe --single-threaded foo.zig
error: unrecognized parameter: '--single-threaded'
Notable changes:
`_i386`, `_i486`, and `_i686` are renamed to `i386`, `i486`,
and `i686` respectively. `std.zig.fmtId` is enhanced to support
formatting `i386` as `@"i386"`.
Some CPU features which are actually CPU models have been
properly flattened, such as `apple_a12`, `apple_a13`, `apple_a7`,
`cortex_a78c`, `exynos_m4`, `neoverse_e1`, `neoverse_n1`,
`neoverse_n2`, `neoverse_v1`.
Some CPU features have been added and some have been removed, following
LLVM's lead.
CSky CPU features support is added.
The idea is to depend on this language feature as little as possible
with the hopes that it can be adjusted to be less of an anti-pattern.
This also helps self-hosted, which does not yet implement
`usingnamespace`, get closer to being able to build compiler-rt.
Lakemont has no x86, no MMX, no SSE and no way of handling any fp-math. In theory LLVM is able to implicitly use the soft-float emulation library calls to legalize any such operation but, given Zig's use of many non-standard features, sometimes we hit a weak spot in the X86 codegen backend.
Consider this as a work-around for this LLVM problem, fixing the problem in LLVM is not so high in my todo list as the target is pretty niche and Intel axed it in '19.
(Commit message by @LemonBoy)
- hash/eql functions moved into a Context object
- *Context functions pass an explicit context
- *Adapted functions pass specialized keys and contexts
- new getPtr() function returns a pointer to value
- remove functions renamed to fetchRemove
- new remove functions return bool
- removeAssertDiscard deleted, use assert(remove(...)) instead
- Keys and values are stored in separate arrays
- Entry is now {*K, *V}, the new KV is {K, V}
- BufSet/BufMap functions renamed to match other set/map types
- fixed iterating-while-modifying bug in src/link/C.zig
- original PR #7949 (incorrectly) patched a generated-file and changes
have subsequently been lost/overwritten
- fix#7947 in a different way: drop `ppc32` because `ppc` already exists
This completes the process. All target CPU features are now
auto-generated by the tools/update_cpu_features.zig script, which
contains all the overrides.
Invoking this tool against LLVM 12rc2 now produces an empty git diff.
With this change, added & modified cpus & features participate in the
same pruning system, and sorting takes into account the zig name, not
the pre-modified llvm name.
The modified target files in this commit are due to the improved
sorting and pruning.
The script now fully supports extra cpus & features.
