| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Resolves: #22343
|
|
Acts as a replacement for `addSharedLibrary` and `addStaticLibrary`, but
linking mode can be changed more easily in build.zig, for example:
In library:
```zig
const linkage = b.option(std.builtin.LinkMode, "linkage", "Link mode for a foo_bar library") orelse .static; // or other default
const lib = b.addLibrary(.{
.linkage = linkage,
.name = "foo_bar",
.root_module = mod,
});
```
In consumer:
```zig
const dep_foo_bar = b.dependency("foo_bar", .{
.target = target,
.optimize = optimize,
.linkage = .static // or dynamic
});
mod.linkLibrary(dep_foor_bar.artifact("foo_bar"));
```
It also matches nicely with `linkLibrary` name.
Signed-off-by: Eric Joldasov <bratishkaerik@landless-city.net>
|
|
Compilation pipeline: spawn Jobs earlier that produce linker inputs
|
|
|
|
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.
|
|
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
|
|
Wait for reported spawn success or failure before trying to write to the stdio pipe in the build runner.
Hopefully fixes `error.BrokenPipe` failures
|
|
We can still often determine a comptime result based on the type, even
if the pointer is runtime-known.
Also, we previously used load -> is non null instead of AIR
`is_non_null_ptr` if the pointer is comptime-known, but that's a bad
heuristic. Instead, we should check for the pointer to be
comptime-known, *and* for the load to be comptime-known, and only in
that case should we call `Sema.analyzeIsNonNull`.
Resolves: #22556
|
|
|
|
Fix building the standard library without CFI directives
|
|
`std.zig.Server`
The previous logic here was trying to assume that custom test runners
never used `std.zig.Server` to communicate with the build runner;
however, it was flawed, because modifying the `test_runner` field on
`Step.Compile` would not update this flag. That might have been
intentional (allowing a way for the user to specify a custom test runner
which *does* use the compiler server protocol), but if so, it was a
flawed API, since it was too easy to update one field without updating
the other.
Instead, bundle these two pieces of state into a new type
`std.Build.Step.Compile.TestRunner`. When passing a custom test runner,
you are now *provided* to specify whether it is a "simple" runner, or
whether it uses the compiler server protocol.
This is a breaking change, but is unlikely to affect many people, since
custom test runners are seldom used in the wild.
|
|
|
|
Resolves: #19832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 133abdeda2994886c3476a3faf53f8a911513b32 but keeps
the tests disabled for the wasm target, which is the only configuration
that seems to fail, even though the error looks like a frontend error.
|
|
std.builtin.Type renames, and make it easier to modify std.builtin
|
|
tracking issue #22510
|
|
|
|
This was done by regex substitution with `sed`. I then manually went
over the entire diff and fixed any incorrect changes.
This diff also changes a lot of `callconv(.C)` to `callconv(.c)`, since
my regex happened to also trigger here. I opted to leave these changes
in, since they *are* a correct migration, even if they're not the one I
was trying to do!
|
|
now it's smarter about omitting tls stuff if there end up being no
TLS data sections
|
|
export by default means export, as expected. if you want hidden
visibility then use hidden visibility.
|
|
fix calculation of alignment and size
include __tls_align and __tls_size globals along with __tls_base
include them only if the TLS segment is emitted
add missing reloc logic for memory_addr_tls_sleb
fix name of data segments to include only the prefix
|
|
|
|
Object being linked has neither functions nor globals named "foo" or
"bar" and so these names correctly fail to be exported when creating an
executable.
|
|
I intentionally simplified the target features functionality to use the
target features that are explicitly specified to the linker and ignore
the "tooling conventions"
this makes the wasm linker behave the same as ELF, COFF, and MachO.
|
|
this tests for importing a function table, but the example source does
not try to use an imported table, so it's a useless check. it's unclear
what the behavior is even supposed to do in this case.
the other two cases are left alone.
|
|
- doesn't run the exe
- checks for data segment named .rodata which is not a thing
- checks for data segment named .bss which is not needed
|
|
This test passes now, but let's not run it for the other optimization
modes since they don't affect linker behavior.
|
|
the other optimization modes don't affect linking
|
|
The purpose of this test is unclear. It checks for the existence of bss
section which is completely unnecessary since those zeroes can be
omitted from the binary.
Furthermore the code generated for __wasm_init_memory looks wrong.
Finally, the CheckObject DSL is brittle, it only checks for exact
matches of entire lines in an ad-hoc text format. Conclusion, it's a bad
test, delete it.
|
|
|
|
|
|
|
|
|
|
Also improve the source locations when this validation fails.
Resolves: #22465
|
|
And add test coverage for the compile error in question.
|
|
`Type.hasWellDefinedLayout` was in disagreement with pointer loading
logic about auto-layout structs with zero fields, `struct {}`. For
consistency, these types should not have a well-defined layout.
This is technically a breaking change.
|
