340 Commits

Author SHA1 Message Date
Andrew Kelley
fcafc63f3d inline assembly: use types
until now these were stringly typed.

it's kinda obvious when you think about it.
2025-07-16 10:23:02 -07:00
Linus Groh
eb37552536 Remove numerous things deprecated during the 0.14 release cycle
Basically everything that has a direct replacement or no uses left.

Notable omissions:

- std.ArrayHashMap: Too much fallout, needs a separate cleanup.
- std.debug.runtime_safety: Too much fallout.
- std.heap.GeneralPurposeAllocator: Lots of references to it remain, not
  a simple find and replace as "debug allocator" is not equivalent to
  "general purpose allocator".
- std.io.Reader: Is being reworked at the moment.
- std.unicode.utf8Decode(): No replacement, needs a new API first.
- Manifest backwards compat options: Removal would break test data used
  by TestFetchBuilder.
- panic handler needs to be a namespace: Many tests still rely on it
  being a function, needs a separate cleanup.
2025-07-11 08:17:43 +02:00
Andrew Kelley
9c8aef55b4 std.fmt.format: use {t} for tag name rather than {s}
prevents footgun when formatted type changes from string to enum
2025-07-07 22:43:52 -07:00
Andrew Kelley
30c2921eb8 compiler: update a bunch of format strings 2025-07-07 22:43:52 -07:00
Andrew Kelley
f71d97e4cb update compiler source to new APIs 2025-07-07 22:43:52 -07:00
Andrew Kelley
0e37ff0d59 std.fmt: breaking API changes
added adapter to AnyWriter and GenericWriter to help bridge the gap
between old and new API

make std.testing.expectFmt work at compile-time

std.fmt no longer has a dependency on std.unicode. Formatted printing
was never properly unicode-aware. Now it no longer pretends to be.

Breakage/deprecations:
* std.fs.File.reader -> std.fs.File.deprecatedReader
* std.fs.File.writer -> std.fs.File.deprecatedWriter
* std.io.GenericReader -> std.io.Reader
* std.io.GenericWriter -> std.io.Writer
* std.io.AnyReader -> std.io.Reader
* std.io.AnyWriter -> std.io.Writer
* std.fmt.format -> std.fmt.deprecatedFormat
* std.fmt.fmtSliceEscapeLower -> std.ascii.hexEscape
* std.fmt.fmtSliceEscapeUpper -> std.ascii.hexEscape
* std.fmt.fmtSliceHexLower -> {x}
* std.fmt.fmtSliceHexUpper -> {X}
* std.fmt.fmtIntSizeDec -> {B}
* std.fmt.fmtIntSizeBin -> {Bi}
* std.fmt.fmtDuration -> {D}
* std.fmt.fmtDurationSigned -> {D}
* {} -> {f} when there is a format method
* format method signature
  - anytype -> *std.io.Writer
  - inferred error set -> error{WriteFailed}
  - options -> (deleted)
* std.fmt.Formatted
  - now takes context type explicitly
  - no fmt string
2025-07-07 22:43:51 -07:00
Andrew Kelley
0b3f0124dc std.io: move getStdIn, getStdOut, getStdErr functions to fs.File
preparing to rearrange std.io namespace into an interface

how to upgrade:

std.io.getStdIn() -> std.fs.File.stdin()
std.io.getStdOut() -> std.fs.File.stdout()
std.io.getStdErr() -> std.fs.File.stderr()
2025-07-07 22:43:51 -07:00
Andrew Kelley
34f64432b0 remove usingnamespace from the language
closes #20663
2025-07-07 13:39:48 -07:00
mlugg
c4ec382fc8
InternPool: store the Nav types are named after
When the name strategy is `.parent`, the DWARF info really wants to know
what `Nav` we were named after to emit a more optimal hierarchy.
2025-06-12 13:55:41 +01:00
Jacob Young
0bf8617d96 x86_64: add support for pie executables 2025-06-06 23:42:14 -07:00
Jacob Young
b483defc5a Legalize: implement scalarization of binary operations 2025-05-31 18:54:28 -04:00
Jacob Young
8bacf3e757 x86_64: implement integer @reduce(.Max) 2025-05-28 15:10:22 -04:00
Jacob Young
3fd3358f37 x86_64: implement integer @reduce(.Min) 2025-05-28 15:10:22 -04:00
Jacob Young
a4a1ebdeed x86_64: implement optimized float @reduce(.Mul) 2025-05-28 15:10:22 -04:00
Jacob Young
d69f4c48fc x86_64: rewrite bitwise @reduce 2025-05-28 15:10:22 -04:00
mlugg
92c63126e8 compiler: tlv pointers are not comptime-known
Pointers to thread-local variables do not have their addresses known
until runtime, so it is nonsensical for them to be comptime-known. There
was logic in the compiler which was essentially attempting to treat them
as not being comptime-known despite the pointer being an interned value.
This was a bit of a mess, the check was frequent enough to actually show
up in compiler profiles, and it was very awkward for backends to deal
with, because they had to grapple with the fact that a "constant" they
were lowering might actually require runtime operations.

So, instead, do not consider these pointers to be comptime-known in
*any* way. Never intern such a pointer; instead, when the address of a
threadlocal is taken, emit an AIR instruction which computes the pointer
at runtime. This avoids lots of special handling for TLVs across
basically all codegen backends; of all somewhat-functional backends, the
only one which wasn't improved by this change was the LLVM backend,
because LLVM pretends this complexity around threadlocals doesn't exist.

This change simplifies Sema and codegen, avoids a potential source of
bugs, and potentially improves Sema performance very slightly by
avoiding a non-trivial check on a hot path.
2025-05-27 19:23:11 +01:00
Matthew Lugg
23c817548b
Merge pull request #23836 from mlugg/incr-fixes
Incremental fixes, refactor `Zcu.File`
2025-05-20 03:25:19 +01:00
mlugg
37a9a4e0f1
compiler: refactor Zcu.File and path representation
This commit makes some big changes to how we track state for Zig source
files. In particular, it changes:

* How `File` tracks its path on-disk
* How AstGen discovers files
* How file-level errors are tracked
* How `builtin.zig` files and modules are created

The original motivation here was to address incremental compilation bugs
with the handling of files, such as #22696. To fix this, a few changes
are necessary.

Just like declarations may become unreferenced on an incremental update,
meaning we suppress analysis errors associated with them, it is also
possible for all imports of a file to be removed on an incremental
update, in which case file-level errors for that file should be
suppressed. As such, after AstGen, the compiler must traverse files
(starting from analysis roots) and discover the set of "live files" for
this update.

Additionally, the compiler's previous handling of retryable file errors
was not very good; the source location the error was reported as was
based only on the first discovered import of that file. This source
location also disappeared on future incremental updates. So, as a part
of the file traversal above, we also need to figure out the source
locations of imports which errors should be reported against.

Another observation I made is that the "file exists in multiple modules"
error was not implemented in a particularly good way (I get to say that
because I wrote it!). It was subject to races, where the order in which
different imports of a file were discovered affects both how errors are
printed, and which module the file is arbitrarily assigned, with the
latter in turn affecting which other files are considered for import.
The thing I realised here is that while the AstGen worker pool is
running, we cannot know for sure which module(s) a file is in; we could
always discover an import later which changes the answer.

So, here's how the AstGen workers have changed. We initially ensure that
`zcu.import_table` contains the root files for all modules in this Zcu,
even if we don't know any imports for them yet. Then, the AstGen
workers do not need to be aware of modules. Instead, they simply ignore
module imports, and only spin off more workers when they see a by-path
import.

During AstGen, we can't use module-root-relative paths, since we don't
know which modules files are in; but we don't want to unnecessarily use
absolute files either, because those are non-portable and can make
`error.NameTooLong` more likely. As such, I have introduced a new
abstraction, `Compilation.Path`. This type is a way of representing a
filesystem path which has a *canonical form*. The path is represented
relative to one of a few special directories: the lib directory, the
global cache directory, or the local cache directory. As a fallback, we
use absolute (or cwd-relative on WASI) paths. This is kind of similar to
`std.Build.Cache.Path` with a pre-defined list of possible
`std.Build.Cache.Directory`, but has stricter canonicalization rules
based on path resolution to make sure deduplicating files works
properly. A `Compilation.Path` can be trivially converted to a
`std.Build.Cache.Path` from a `Compilation`, but is smaller, has a
canonical form, and has a digest which will be consistent across
different compiler processes with the same lib and cache directories
(important when we serialize incremental compilation state in the
future). `Zcu.File` and `Zcu.EmbedFile` both contain a
`Compilation.Path`, which is used to access the file on-disk;
module-relative sub paths are used quite rarely (`EmbedFile` doesn't
even have one now for simplicity).

After the AstGen workers all complete, we know that any file which might
be imported is definitely in `import_table` and up-to-date. So, we
perform a single-threaded graph traversal; similar to what
`resolveReferences` plays for `AnalUnit`s, but for files instead. We
figure out which files are alive, and which module each file is in. If a
file turns out to be in multiple modules, we set a field on `Zcu` to
indicate this error. If a file is in a different module to a prior
update, we set a flag instructing `updateZirRefs` to invalidate all
dependencies on the file. This traversal also discovers "import errors";
these are errors associated with a specific `@import`. With Zig's
current design, there is only one possible error here: "import outside
of module root". This must be identified during this traversal instead
of during AstGen, because it depends on which module the file is in. I
tried also representing "module not found" errors in this same way, but
it turns out to be much more useful to report those in Sema, because of
use cases like optional dependencies where a module import is behind a
comptime-known build option.

For simplicity, `failed_files` now just maps to `?[]u8`, since the
source location is always the whole file. In fact, this allows removing
`LazySrcLoc.Offset.entire_file` completely, slightly simplifying some
error reporting logic. File-level errors are now directly built in the
`std.zig.ErrorBundle.Wip`. If the payload is not `null`, it is the
message for a retryable error (i.e. an error loading the source file),
and will be reported with a "file imported here" note pointing to the
import site discovered during the single-threaded file traversal.

The last piece of fallout here is how `Builtin` works. Rather than
constructing "builtin" modules when creating `Package.Module`s, they are
now constructed on-the-fly by `Zcu`. The map `Zcu.builtin_modules` maps
from digests to `*Package.Module`s. These digests are abstract hashes of
the `Builtin` value; i.e. all of the options which are placed into
"builtin.zig". During the file traversal, we populate `builtin_modules`
as needed, so that when we see this imports in Sema, we just grab the
relevant entry from this map. This eliminates a bunch of awkward state
tracking during construction of the module graph. It's also now clearer
exactly what options the builtin module has, since previously it
inherited some options arbitrarily from the first-created module with
that "builtin" module!

The user-visible effects of this commit are:
* retryable file errors are now consistently reported against the whole
  file, with a note pointing to a live import of that file
* some theoretical bugs where imports are wrongly considered distinct
  (when the import path moves out of the cwd and then back in) are fixed
* some consistency issues with how file-level errors are reported are
  fixed; these errors will now always be printed in the same order
  regardless of how the AstGen pass assigns file indices
* incremental updates do not print retryable file errors differently
  between updates or depending on file structure/contents
* incremental updates support files changing modules
* incremental updates support files becoming unreferenced

Resolves: #22696
2025-05-18 17:37:02 +01:00
Jacob Young
a3b0c242b0 x86_64: rewrite @splat 2025-05-17 18:00:17 -04:00
Jacob Young
6d68a494c8 x86_64: rewrite vector +| 2025-05-17 02:08:41 -04:00
Andrew Kelley
f32a5d349d std: eradicate u29 and embrace std.mem.Alignment 2025-04-13 02:20:32 -04:00
Mason Remaley
06ee383da9
compiler: allow @import of ZON without a result type
In particular, this allows importing `build.zig.zon` at comptime.
2025-04-02 05:53:22 +01:00
David Rubin
89db4f2e93 Sema: use unwrapped generic owner in getFuncInstanceIes 2025-03-24 19:04:10 +00:00
Jacob Young
c5c1c8538d x86_64: rewrite wrapping multiplication 2025-03-21 21:51:08 -04:00
Alex Rønne Petersen
5c44934e20 Move the compiler's LLVM bitcode builder to std.zig.llvm. 2025-02-27 01:32:49 -05:00
Alex Rønne Petersen
6ba785584a
compiler: Implement @disableIntrinsics() builtin function.
Closes #21833.
Closes #22110.
2025-02-23 04:08:56 +01:00
Meghan Denny
9142482372
std.ArrayList: popOrNull() -> pop() [v2] (#22720) 2025-02-10 04:21:31 +00:00
mlugg
3ce857d054
Sema: fix incorrectly succeeding type resolution
Resolves: #21436
2025-02-05 18:31:39 +00:00
mlugg
3ca588bcc6
compiler: integrate importing ZON with incremental compilation
The changes from a few commits earlier, where semantic analysis no
longer occurs if any Zig files failed to lower to ZIR, mean `file`
dependencies are no longer necessary! However, we now need them for ZON
files, to be invalidated whenever a ZON file changes.
2025-02-04 16:20:29 +00:00
Mason Remaley
13c6eb0d71
compiler,std: implement ZON support
This commit allows using ZON (Zig Object Notation) in a few ways.

* `@import` can be used to load ZON at comptime and convert it to a
  normal Zig value. In this case, `@import` must have a result type.
* `std.zon.parse` can be used to parse ZON at runtime, akin to the
  parsing logic in `std.json`.
* `std.zon.stringify` can be used to convert arbitrary data structures
  to ZON at runtime, again akin to `std.json`.
2025-02-03 09:14:37 +00:00
Jacob Young
b9531f5de6 x86_64: rewrite float vector conversions 2025-01-31 23:00:34 -05:00
Matthew Lugg
3767b08039
Merge pull request #22602 from mlugg/incr-embedfile
incremental: handle `@embedFile`
2025-01-26 01:41:56 +00:00
mlugg
f47b8de2ad
incremental: handle @embedFile
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.
2025-01-25 06:07:08 +00:00
Jacob Young
c7433212d1 x86_64: rewrite scalar and vector int @min and @max 2025-01-24 21:02:32 -05:00
Jacob Young
b1fa89439a x86_64: rewrite float vector @abs and equality comparisons 2025-01-24 20:56:11 -05:00
mlugg
1bce01de97 compiler: pass error return traces everywhere 2025-01-22 02:22:56 -05:00
mlugg
0ec6b2dd88 compiler: simplify generic functions, fix issues with inline calls
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
2025-01-21 02:41:42 +00:00
mlugg
9804cc8bc6
all: update to std.builtin.Type.{Pointer,Array,StructField} field renames 2025-01-16 12:49:58 +00:00
mlugg
d00e05f186
all: update to std.builtin.Type.Pointer.Size field renames
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!
2025-01-16 12:46:29 +00:00
Andrew Kelley
a7bd1a631b wasm codegen: fix mistaking extern data as function 2025-01-15 15:11:37 -08:00
Andrew Kelley
eb943890d9 resolve merge conflicts
with 497592c9b45a94fb7b6028bf45b80f183e395a9b
2025-01-15 15:11:36 -08:00
Andrew Kelley
91efc5c98b wasm linker: fix calling imported functions
and more disciplined type safety for output function indexes
2025-01-15 15:11:35 -08:00
Andrew Kelley
458f658b42 wasm linker: implement missing logic
fix some compilation errors for reworked Emit now that it's actually
referenced

introduce DataSegment.Id for sorting data both from object files and
from the Zcu.

introduce optimization: data segment sorting includes a descending sort
on reference count so that references to data can be smaller integers
leading to better LEB encodings. this optimization is skipped for object
files.

implement uav address access function which is based on only 1 hash
table lookup to find out the offset after sorting.
2025-01-15 15:11:35 -08:00
Andrew Kelley
d6b42e585b wasm linker: implement name subsection
unlike the previous implementation, we can simply iterate an array.
2025-01-15 15:11:35 -08:00
Andrew Kelley
c96e23632f frontend: add const to more Zcu pointers 2025-01-15 15:11:35 -08:00
Jacob Young
02692ad78c cbe: fix miscomps of the compiler 2025-01-10 06:10:15 -05:00
Jacob Young
dde3116e50
Dwarf: implement new incremental line number update API 2025-01-05 02:20:56 +00:00
mlugg
f01029c4af
incremental: new AnalUnit to group dependencies on std.builtin decls
This commit reworks how values like the panic handler function are
memoized during a compiler invocation. Previously, the value was
resolved by whichever analysis requested it first, and cached on `Zcu`.
This is problematic for incremental compilation, as after the initial
resolution, no dependencies are marked by users of this memoized state.
This is arguably acceptable for `std.builtin`, but it's definitely not
acceptable for the panic handler/messages, because those can be set by
the user (`std.builtin.Panic` checks `@import("root").Panic`).

So, here we introduce a new kind of `AnalUnit`, called `memoized_state`.
There are 3 such units:
* `.{ .memoized_state = .va_list }` resolves the type `std.builtin.VaList`
* `.{ .memoized_state = .panic }` resolves `std.Panic`
* `.{ .memoized_state = .main }` resolves everything else we want

These units essentially "bundle" the resolution of their corresponding
declarations, storing the results into fields on `Zcu`. This way, when,
for instance, a function wants to call the panic handler, it simply runs
`ensureMemoizedStateResolved`, registering one dependency, and pulls the
values from the `Zcu`. This "bundling" minimizes dependency edges. The 3
units are separated to allow them to act independently: for instance,
the panic handler can use `std.builtin.Type` without triggering a
dependency loop.
2025-01-04 07:51:19 +00:00
mlugg
f818098971
incremental: correctly return error.AnalysisFail when type structure changes
`Zcu.PerThead.ensureTypeUpToDate` is set up in such a way that it only
returns the updated type the first time it is called. In general, that's
okay; however, the exception is that we want the function to continue
returning `error.AnalysisFail` when the type has been lost, or its
number of captures changed.

Therefore, the check for this case now happens before the up-to-date
success return.

For simplicity, the number of captures is now handled by intentionally
losing the instruction in `Zcu.mapOldZirToNew`, since there is nothing
to gain from tracking a type when old instances of it can never be
reused.
2025-01-04 05:44:29 +00:00
Jacob Young
ec60156f18 InternPool: fix leak when the last namespace bucket is full 2024-12-29 15:28:40 -05:00