| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
incremental: handle `@embedFile`
|
|
Disable LTO by default + some LTO fixes
|
|
x86_64: rewrite `@abs` on floats
|
|
LLD has too many LTO bugs, and we're dropping the LLD dependency soon anyway.
|
|
|
|
No longer needed since we disable LTO for mingw32.
|
|
* compiler-rt and mingw32 have both run into LLD bugs, and LLVM disables LTO for
its compiler-rt, so disable LTO for these.
* While we haven't run into any bugs in it, LLVM disables LTO for its libtsan,
so follow suit just to be safe.
* Allow LTO for libfuzzer as LLVM does.
|
|
If this isn't done, LTO can completely miscompile the input bitcode modules for
certain targets where we need to explicitly set these ABIs (because LLVM's
defaults are bad).
|
|
LLVM.
See 652c5151429e279f70396ee601416c87a70c1bec. Better to avoid relying on default
LLVM behavior going forward.
|
|
Necessary because of: https://github.com/llvm/llvm-project/commit/dc665fa5f5b8b572479ceac6bf32e0174de65f1e
|
|
Uses of `@embedFile` register dependencies on the corresponding
`Zcu.EmbedFile`. At the start of every update, we iterate all embedded
files and update them if necessary, and invalidate the dependencies if
they changed.
In order to properly integrate with the lazy analysis model, failed
embed files are now reported by the `AnalUnit` which actually used
`@embedFile`; the filesystem error is stored in the `Zcu.EmbedFile`.
An incremental test is added covering incremental updates to embedded
files, and I have verified locally that dependency invalidation is
working correctly.
|
|
compiler: yet more panic handler changes
|
|
|
|
|
|
|
|
|
|
|
|
The new simplifications to the panic handler have eliminated the need
for this piece of memoized state.
|
|
|
|
Now that we propagate the error return trace to all `callconv(.auto)`
functions, passing it explicitly to panic handlers is redundant.
|
|
|
|
and remove faulty assertion. When a prelink task fails, the
completed_prelink_tasks counter will not decrement.
A future improvement will be needed to make the pipeline fully robust
and handle failed prelink tasks, followed by updates in which those
tasks succeed, and compilation proceeds like normal.
Currently if a prelink task fails, the Compilation will be left in a
state unrecoverable by an incremental update.
|
|
* `std.builtin.Panic` -> `std.builtin.panic`, because it is a namespace.
* `root.Panic` -> `root.panic` for the same reason. There are type
checks so that we still allow the legacy `pub fn panic` strategy in
the 0.14.0 release.
* `std.debug.SimplePanic` -> `std.debug.simple_panic`, same reason.
* `std.debug.NoPanic` -> `std.debug.no_panic`, same reason.
* `std.debug.FormattedPanic` is now a function `std.debug.FullPanic`
which takes as input a `panicFn` and returns a namespace with all the
panic functions. This handles the incredibly common case of just
wanting to override how the message is printed, whilst keeping nice
formatted panics.
* Remove `std.builtin.panic.messages`; now, every safety panic has its
own function. This reduces binary bloat, as calls to these functions
no longer need to prepare any arguments (aside from the error return
trace).
* Remove some legacy declarations, since a zig1.wasm update has
happened. Most of these were related to the panic handler, but a quick
grep for "zig1" brought up a couple more results too.
Also, add some missing type checks to Sema.
Resolves: #22584
formatted -> full
|
|
As is done for root_strip and root_error_tracing.
|
|
This moves the default value logic to Package.Module.create() instead and makes
it so that Compilation.Config.any_unwind_tables is computed similarly to
any_sanitize_thread, any_fuzz, etc. It turns out that for any_unwind_tables, we
only actually care if unwind tables are enabled at all, not at what level.
|
|
For some reason we accepted --eh-frame-hdr, but not --no-eh-frame-hdr, despite
accepting the latter as a -Wl linker flag.
|
|
`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model
|
|
This is more verbose, but at least we now get a compile error instead of UB when
a new feature is added to std.Target.wasm.Feature but not to link.Wasm.Feature.
|
|
This will mainly be used when targeting our wasm2c implementation which has no
problem with zero-length bulk memory operations, as a non-standard extension.
|
|
compiler: include error trace in all functions, implement for x86_64 backend
|
|
|
|
|
|
|
|
Resolves: #22343
|
|
See: https://github.com/WebAssembly/tool-conventions/pull/235
This is not *quite* using the same features as the spec'd lime1 model because
LLVM 19 doesn't have the level of feature granularity that we need for that.
This will be fixed once we upgrade to LLVM 20.
Part of #21818.
|
|
Apparently the WebAssembly spec requires these instructions to trap if the
computed memory access could be out of bounds, even if the length is zero.
Really a rather bizarre design choice.
|
|
|
|
Compilation pipeline: spawn Jobs earlier that produce linker inputs
|
|
|
|
Namely:
* alpha
* hppa
* ia64
* microblaze
* nios2
* or1k
* s390
* sh
|
|
Turns out that even modern Debian aarch64 glibc libc_nonshared.a has
references to _init, meaning that the previous commit caused a
regression when trying to build any -lc executable on that target.
This commit backs out the changes to LibCInstallation.
There is still a fork in the road coming up when the self-hosted ELF
linker becomes load bearing on that target.
|
|
crti.o/crtn.o is a legacy strategy for calling constructor functions
upon object loading that has been superseded by the
init_array/fini_array mechanism.
Zig code depends on neither, since the language intentionally has no way
to initialize data at runtime, but alas the Zig linker still must
support this feature since popular languages depend on it.
Anyway, the way it works is that crti.o has the machine code prelude of
two functions called _init and _fini, each in their own section with the
respective name. crtn.o has the machine code instructions comprising the
exitlude for each function. In between, objects use the .init and .fini
link section to populate the function body.
This function is then expected to be called upon object initialization
and deinitialization.
This mechanism is depended on by libc, for example musl and glibc, but
only for older ISAs. By the time the libcs gained support for newer
ISAs, they had moved on to the init_array/fini_array mechanism instead.
For the Zig linker, we are trying to move the linker towards
order-independent objects which is incompatible with the legacy
crti/crtn mechanism.
Therefore, this commit drops support entirely for crti/crtn mechanism,
which is necessary since the other commits in this branch make it
nondeterministic in which order the libc objects and the other link
inputs are sent to the linker.
The linker is still expected to produce a deterministic output, however,
by ignoring object input order for the purposes of symbol resolution.
|
|
|
|
|
|
Move all the remaining Jobs that produce linker inputs to be spawned
earlier in the pipeline and registered with link_task_wait_group.
|
|
|
|
This means doing more work in parallel which is already good, but it's
also a correctnes fix because we need link_task_wait_group.wait() to
ensure that no more linker inputs will be generated.
|
|
The original motivation here was to fix regressions caused by #22414.
However, while working on this, I ended up discussing a language
simplification with Andrew, which changes things a little from how they
worked before #22414.
The main user-facing change here is that any reference to a prior
function parameter, even if potentially comptime-known at the usage
site or even not analyzed, now makes a function generic. This applies
even if the parameter being referenced is not a `comptime` parameter,
since it could still be populated when performing an inline call. This
is a breaking language change.
The detection of this is done in AstGen; when evaluating a parameter
type or return type, we track whether it referenced any prior parameter,
and if so, we mark this type as being "generic" in ZIR. This will cause
Sema to not evaluate it until the time of instantiation or inline call.
A lovely consequence of this from an implementation perspective is that
it eliminates the need for most of the "generic poison" system. In
particular, `error.GenericPoison` is now completely unnecessary, because
we identify generic expressions earlier in the pipeline; this simplifies
the compiler and avoids redundant work. This also entirely eliminates
the concept of the "generic poison value". The only remnant of this
system is the "generic poison type" (`Type.generic_poison` and
`InternPool.Index.generic_poison_type`). This type is used in two
places:
* During semantic analysis, to represent an unknown result type.
* When storing generic function types, to represent a generic parameter/return type.
It's possible that these use cases should instead use `.none`, but I
leave that investigation to a future adventurer.
One last thing. Prior to #22414, inline calls were a little inefficient,
because they re-evaluated even non-generic parameter types whenever they
were called. Changing this behavior is what ultimately led to #22538.
Well, because the new logic will mark a type expression as generic if
there is any change its resolved type could differ in an inline call,
this redundant work is unnecessary! So, this is another way in which the
new design reduces redundant work and complexity.
Resolves: #22494
Resolves: #22532
Resolves: #22538
|
