This change modifies `Zcu.ErrorMsg` to store a `Zcu.LazySrcLoc` rather
than a `Zcu.SrcLoc`. Everything else is dominoes.
The reason for this change is incremental compilation. If a failed
`AnalUnit` is up-to-date on an update, we want to re-use the old error
messages. However, the file containing the error location may have been
modified, and `SrcLoc` cannot survive such a modification. `LazySrcLoc`
is designed to be correct across incremental updates. Therefore, we
defer source location resolution until `Compilation` gathers the compile
errors into the `ErrorBundle`.
This commit reworks our representation of exported Decls and values in
Zcu to be memory-optimized and trivially serialized.
All exports are now stored in the `all_exports` array on `Zcu`. An
`AnalUnit` which performs an export (either through an `export`
annotation or by containing an analyzed `@export`) gains an entry into
`single_exports` if it performs only one export, or `multi_exports` if
it performs multiple.
We no longer store a persistent mapping from a `Decl`/value to all
exports of that entity; this state is not necessary for the majority of
the pipeline. Instead, we construct it in `Zcu.processExports`, just
before flush. This does not affect the algorithmic complexity of
`processExports`, since this function already iterates all exports in
the `Zcu`.
The elimination of `decl_exports` and `value_exports` led to a few
non-trivial backend changes. The LLVM backend has been wrangled into a
more reasonable state in general regarding exports and externs. The C
backend is currently disabled in this commit, because its support for
`export` was quite broken, and that was exposed by this work -- I'm
hoping @jacobly0 will be able to pick this up!
This patch is a pure rename plus only changing the file path in
`@import` sites, so it is expected to not create version control
conflicts, even when rebasing.
Deprecated aliases that are now compile errors:
- `std.fs.MAX_PATH_BYTES` (renamed to `std.fs.max_path_bytes`)
- `std.mem.tokenize` (split into `tokenizeAny`, `tokenizeSequence`, `tokenizeScalar`)
- `std.mem.split` (split into `splitSequence`, `splitAny`, `splitScalar`)
- `std.mem.splitBackwards` (split into `splitBackwardsSequence`, `splitBackwardsAny`, `splitBackwardsScalar`)
- `std.unicode`
+ `utf16leToUtf8Alloc`, `utf16leToUtf8AllocZ`, `utf16leToUtf8`, `fmtUtf16le` (all renamed to have capitalized `Le`)
+ `utf8ToUtf16LeWithNull` (renamed to `utf8ToUtf16LeAllocZ`)
- `std.zig.CrossTarget` (moved to `std.Target.Query`)
Deprecated `lib/std/std.zig` decls were deleted instead of made a `@compileError` because the `refAllDecls` in the test block would trigger the `@compileError`. The deleted top-level `std` namespaces are:
- `std.rand` (renamed to `std.Random`)
- `std.TailQueue` (renamed to `std.DoublyLinkedList`)
- `std.ChildProcess` (renamed/moved to `std.process.Child`)
This is not exhaustive. Deprecated aliases that I didn't touch:
+ `std.io.*`
+ `std.Build.*`
+ `std.builtin.Mode`
+ `std.zig.c_translation.CIntLiteralRadix`
+ anything in `src/`
Support linking against tbd-v3 SDKs such as those bundled with
Xcode 10.3 → 11.3.1 .
- Map target os=`ios` and abi=`macabi` to macho.PLATFORM.MACCATALYST.
This allows for matches against tbdv4 targets, eg. `x86_64-maccatalyst`.
- When parsing old tbdv3 files with `zippered` platform, we append
[`ARCH-macos`, `ARCH-maccatalyst`] to list of "tbd" targets. This
enables linking for standard targets like `ARCH-macos-none` and
maccatalyst targets `ARCH-ios-macabi`.
- Update mappings for macho platform and zig target macabi. While this
is not full maccatalyst support, a basic exe can be built as follows:
```
zig libc > libc.txt
zig build-exe z0.zig --libc libc.txt -target x86_64-ios-macabi
```
closes#19110
In `ld -r` mode, the linker will emit `N_GSYM` for any defined
external symbols as well as private externals. In the former case,
the thing is easy since `N_EXT` bit will be set in the nlist's type.
In the latter however we will encounter a local symbol with `N_PEXT`
bit set (non-extern, but was private external) which we also need
to include when resolving symbol stabs.
The major change in the logic for parsing symbol stabs per input
object file is that we no longer try to force-resolve a `N_GSYM`
as a global symbol. This was a mistake since every symbol stab
always describes a symbol defined within the parsed input object file.
We then work out if we should forward `N_GSYM` in the output symtab
after we have resolved all symbols, but never before - intel we lack
when initially parsing symbol stabs. Therefore, we simply record
which symbol has a debug symbol stab, and work out its precise type
when emitting output symtab after symbol resolution has been done.
