* Introduce the `--autofix` CLI flag when building an executable,
object, or library.
* Refactor std.zig.render to use a struct parameter to make it easier
to add/remove fields from the struct.
* Introduce a "Fixups" concept to std.zig.render which can perform
edits while rendering code, while leaving the Ast read-only.
* Add a fixup for adding a discard after a variable declaration.
* Update the Module code to check for fixable errors after AstGen
lowering.
Improvements that need to be made before this can be merged:
* Introduce an error for "pointless discard" and a fixup for it so that
--autofix can undo the effects of itself when a variable becomes
used.
* Support local variables as well as local constants.
* Support captures in addition to local variables and constants.
* Integrate properly with incremental compilation.
* Integrate with the Zig build system.
* Distinguish between AstGen errors that can be autofixed and those
that cannot.
* Remove std.debug.print statements.
* Only perform fixups when all errors are autofixable errors. However,
suppress all autofixable errors when reporting errors with --autofix.
The purpose of this feature is to satisfy two use cases that
traditionally have been at odds:
* Some people want the guarantee that all Zig code they read has the
property that there are no unused locals.
* Some people find no value from such errors and want to not have to
deal with them.
The problem with an `--allow-unused` flag is that people from the second
group will use it, and then some projects will fail to compile without
the flag enabled.
I like to think of Zig as having "inline warnings". The warnings are
there, inside your source code, next to the relevant lines, ready to be
noticed by diffs, code reviews, and when refactoring.
`--autofix` is a way for Zig to automatically insert inline warnings for
those who wish to iterate quickly on a messy codebase.
Before, native glibc and dynamic linker detection attempted to use the
executable's own binary if it was dynamically linked to answer both the
C ABI question and the dynamic linker question. However, this could be
problematic on a system that uses a RUNPATH for the compiler binary,
locking it to an older glibc version, while system binaries such as
/usr/bin/env use a newer glibc version. The problem is that libc.so.6
glibc version will match that of the system while the dynamic linker
will match that of the compiler binary. Executables with these versions
mismatching will fail to run.
Therefore, this commit changes the logic to be the same regardless of
whether the compiler binary is dynamically or statically linked. It
inspects `/usr/bin/env` as an ELF file to find the answer to these
questions, or if there is a shebang line, then it chases the referenced
file recursively. If that does not provide the answer, then the function
falls back to defaults.
This commit also solves a TODO to remove an Allocator parameter to the
detect() function.
This adds the following for passthrough to lld:
- `--print-gc-sections`
- `--print-icf-sections`
- `--print-map`
I am not adding these to the cache manifest, since it does not change
the produced artifacts.
Tested with an example from #11398: it successfully prints the resulting
map and the GC'd sections.
This check is needed because if static/dynamic linking is mixed incorrectly,
it's possible for Clang and LLVM to end up with duplicate "copies" of libc++.
This is not benign: Static variables are not shared, so equality comparisons
that depend on pointers to static variables will fail. One such failure is
std::generic_category(), which causes POSIX error codes to compare as unequal
when passed between LLVM and Clang.
I believe this is the cause of https://github.com/ziglang/zig/issues/11168
In order to avoid affecting build times when Zig is repeatedly invoked,
we only enable this check for "zig env" and "zig version"
This reverts commit 7cbd586ace.
This is causing a fail to build from source:
```
./lib/std/fmt.zig:492:17: error: cannot format optional without a specifier (i.e. {?} or {any})
@compileError("cannot format optional without a specifier (i.e. {?} or {any})");
^
./src/link/MachO/Atom.zig:544:26: note: called from here
log.debug(" RELA({s}) @ {x} => %{d} in object({d})", .{
^
```
I looked at the code to fix it but none of those args are optionals.
* make the setting in the linker backend be non-optional; by this time
all defaults are supposed to be resolved.
* integrate with `zig cc`
* change the CLI parsing to match C compiler parsing, allowing
`--compress-debug-sections` alone to choose a default encoding of
zlib.
MachO linker now handles `-needed-l<name>`, `-needed_library=<name>`
and `-needed_framework=<name>`. While on macOS `-l` is equivalent
to `-needed-l`, and `-framework` to `-needed_framework`, it can be
used to the same effect as on Linux if combined with `-dead_strip_dylibs`.
This commit also adds handling for `-needed_library` which is macOS
specific flag only (in addition to `-needed-l`).
Finally, in order to leverage new linker testing harness, this commit
added ability to specify lowering to those flags via `build.zig`:
`linkSystemLibraryNeeded` (and related), and `linkFrameworkNeeded`.
Includes both traditiona and incremental codepaths with one caveat that
in incremental case, the requested size cannot be smaller than the
default padding size due to prealloc required due to incremental nature
of linking.
Also parse `-headerpad_max_install_names`, however, not actionable just yet -
missing implementation.
Unlike targeting ELF-based OSes such as Linux, resolving system libs
on Darwin should follow one of two strategies: `-search_paths_first`
or `-search_dylibs_first` and hence we defer always forcing linking
a static library to the linker.
Ignore MachO-specific flag -search_paths_first, since it is the default
in zld and ld64.
Also see Jakub's comment[1]:
Changing topic slightly, @motiejus dunno if you noticed, with this
change building arm64 Zig binary fails on macos - it complains about
unknown -search_paths_first flag. This one is an easy fix: we should
ignore it since this is the default behaviour in both ld64 and zld.
[1]: https://github.com/ziglang/zig/pull/11906#issuecomment-1163545849
If page aligned requested pagezero size is 0, skip generating
__PAGEZERO segment.
Add misc improvements to the pipeline, and correctly transfer the
requested __PAGEZERO size to the linker.
Pass `-pagezero_size` to the MachO linker. This is the final
"unsupported linker arg" that I could chase that CGo uses. After this
and #11874 we may be able to fail on an "unsupported linker arg" instead
of emiting a warning.
Test case:
zig=/code/zig/build/zig
CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 CC="$zig cc -target x86_64-macos" CXX="$zig c++ -target x86_64-macos" go build -a -ldflags "-s -w" cgo.go
I compiled a trivial CGo program and executed it on an amd64 Darwin
host.
To be honest, I am not entirely sure what this is doing. This feels
right after reading what this argument does in LLVM sources, but I am by
no means qualified to make MachO pull requests. Will take feedback.
This passes -Wl,-no-pie linker arg. Golang uses that. From the `ld(1)`
man page:
Create a position dependent executable. This is the default.
Not adding to the help text, because this is the default.
Note that the current documentation for the `-z noexecstack` is
incorrect. This indicates that an object *does not* require an
executable stack.
This is actually the default of LLD, and there has never been a way to
override this default by passing `-z execstack` to LLD.
This commit removes the redundant `-z noexecstack` option from
zig build-exe/build-lib/build-obj and ignores the option if passed
to zig cc for compatibility.
As far as I can tell, there is no reason for code to require an
executable stack. This option only exists because the stack was
originally executable by default and some programs came to depend
on that behavior. Instead, mprotect(2) may be used to make memory
pages executable.
