aboutsummaryrefslogtreecommitdiff
path: root/src/main.zig
AgeCommit message (Collapse)Author
2025-02-26switch from "id" to "nonce"Andrew Kelley
mainly this addresses the following use case: 1. Someone creates a template with build.zig.zon, id field included (note that zig init does not create this problem since it generates fresh id every time it runs). 2. User A uses the template, changing package name to "example" but not id field. 3. User B uses the same template, changing package name also to "example", also not changing the id field. Here, both packages have unintentional conflicting logical ids. By making the field a combination of name checksum + random id, this accident is avoided. "nonce" is an OK name for this. Also relaxes errors on remote packages when using `zig fetch`.
2025-02-26CLI: add unit test and improve sanitizeExampleNameAndrew Kelley
2025-02-26zig init: sanitize generated nameAndrew Kelley
Adhere to the new rules: 32 byte limit + must be a valid bare zig identifier
2025-02-26introduce package id and redo hash format againAndrew Kelley
Introduces the `id` field to `build.zig.zon`. Together with name, this represents a globally unique package identifier. This field should be initialized with a 16-bit random number when the package is first created, and then *never change*. This allows Zig to unambiguously detect when one package is an updated version of another. When forking a Zig project, this id should be regenerated with a new random number if the upstream project is still maintained. Otherwise, the fork is *hostile*, attempting to take control over the original project's identity. `0x0000` is invalid because it obviously means a random number wasn't used. `0xffff` is reserved to represent "naked" packages. Tracking issue #14288 Additionally: * Fix bad path in error messages regarding build.zig.zon file. * Manifest validates that `name` and `version` field of build.zig.zon are maximum 32 bytes. * Introduce error for root package to not switch to enum literal for name. * Introduce error for root package to omit `id`. * Update init template to generate `id` * Update init template to populate `minimum_zig_version`. * New package hash format changes: - name and version limited to 32 bytes via error rather than truncation - truncate sha256 to 192 bits rather than 40 bits - include the package id This means that, given only the package hashes for a complete dependency tree, it is possible to perform version selection and know the final size on disk, without doing any fetching whatsoever. This prevents wasted bandwidth since package versions not selected do not need to be fetched.
2025-02-26Package: new hash formatAndrew Kelley
legacy format is also supported. closes #20178
2025-02-25main: add `-f{no-}ubsan-rt` to the usage textDavid Rubin
2025-02-25move libubsan to `lib/` and integrate it into `-fubsan-rt`David Rubin
2025-02-22zig build fmtAndrew Kelley
2025-02-22link.MachO: Add support for the -x flag (discard local symbols).Alex Rønne Petersen
This can also be extended to ELF later as it means roughly the same thing there. This addresses the main issue in #21721 but as I don't have a macOS machine to do further testing on, I can't confirm whether zig cc is able to pass the entire cgo test suite after this commit. It can, however, cross-compile a basic program that uses cgo to x86_64-macos-none which previously failed due to lack of -x support. Unlike previously, the resulting symbol table does not contain local symbols (such as C static functions). I believe this satisfies the related donor bounty: https://ziglang.org/news/second-donor-bounty
2025-02-17std.Target: Remove functions that just wrap component functions.Alex Rønne Petersen
Functions like isMinGW() and isGnuLibC() have a good reason to exist: They look at multiple components of the target. But functions like isWasm(), isDarwin(), isGnu(), etc only exist to save 4-8 characters. I don't think this is a good enough reason to keep them, especially given that: * It's not immediately obvious to a reader whether target.isDarwin() means the same thing as target.os.tag.isDarwin() precisely because isMinGW() and similar functions *do* look at multiple components. * It's not clear where we would draw the line. The logical conclusion before this commit would be to also wrap Arch.isX86(), Os.Tag.isSolarish(), Abi.isOpenHarmony(), etc... this obviously quickly gets out of hand. * It's nice to just have a single correct way of doing something.
2025-02-15main: increase thread stack size for non-x86_64 backendsJacob Young
I observed a stack overflow during x86_64 CodeGen in a debug compiler compiled by the llvm backend. This happens while compiling `main.buildOutputType` due to the Air being nested almost 500 levels.
2025-02-13Expand zig fetch usage help doc to explain URL (#22850)Michael Lynch
The current zig fetch help docs tell the user to specify a package's URL, but it's unclear what the URL should be. This change expands the help output to explain what URLs the zig fetch command can handle and provides examples of valid URLs. Related: #20096 A git bundle file seems to be the more accurate term, as it's what git uses in its documentation: https://git-scm.com/docs/git-bundle
2025-02-07compiler: use std.heap.smp_allocatorAndrew Kelley
In main, now this allocator is chosen by default when compiling without libc in ReleaseFast or ReleaseSmall, and not targeting WebAssembly.
2025-02-06std.process: adding hasNonEmptyEnvVar() and using for NO_COLORJohn Benediktsson
2025-02-04compiler: don't perform semantic analysis if there are files without ZIRmlugg
2025-02-04Zcu: remove `*_loaded` fields on `File`mlugg
Instead, `source`, `tree`, and `zir` should all be optional. This is precisely what we're actually trying to model here; and `File` isn't optimized for memory consumption or serializability anyway, so it's fine to use a couple of extra bytes on actual optionals here.
2025-02-03compiler,std: implement ZON supportMason Remaley
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-01-30main: accept and ignore auto-image-base linker optionsAlex Rønne Petersen
Closes #19613.
2025-01-30main: ensure --whole-archive is passed down to linker for -l argumentsAman Karmani
fixes #21971
2025-01-30main: better error message if the global cache dir is unusableachan1989
Fixes #19400
2025-01-29fix(cc): make link and preprocessor logic to be more consistent withzhylmzr
clang's behavior. 1. `zig cc main.c -o /dev/null` shouldn't emit a.out 2. `zig cc -E main.c` and `zig cc -E main -o -` should output to stdout
2025-01-27main: classify empty environment variables as unsetCarter Snook
This matches existing well-specified conventions for e.g. NO_COLOR. Closes #22380.
2025-01-24compiler: yet more panic handler changesmlugg
* `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
2025-01-23compiler: Fix computation of Compilation.Config.any_unwind_tables.Alex Rønne Petersen
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.
2025-01-23compiler: Handle --no-eh-frame-hdr as a regular zig build-* flag too.Alex Rønne Petersen
For some reason we accepted --eh-frame-hdr, but not --no-eh-frame-hdr, despite accepting the latter as a -Wl linker flag.
2025-01-16x86_64: fix crashes compiling the compiler and testsJacob Young
2025-01-15wasm linker: aggressive DODificationAndrew Kelley
The goals of this branch are to: * compile faster when using the wasm linker and backend * enable saving compiler state by directly copying in-memory linker state to disk. * more efficient compiler memory utilization * introduce integer type safety to wasm linker code * generate better WebAssembly code * fully participate in incremental compilation * do as much work as possible outside of flush(), while continuing to do linker garbage collection. * avoid unnecessary heap allocations * avoid unnecessary indirect function calls In order to accomplish this goals, this removes the ZigObject abstraction, as well as Symbol and Atom. These abstractions resulted in overly generic code, doing unnecessary work, and needless complications that simply go away by creating a better in-memory data model and emitting more things lazily. For example, this makes wasm codegen emit MIR which is then lowered to wasm code during linking, with optimal function indexes etc, or relocations are emitted if outputting an object. Previously, this would always emit relocations, which are fully unnecessary when emitting an executable, and required all function calls to use the maximum size LEB encoding. This branch introduces the concept of the "prelink" phase which occurs after all object files have been parsed, but before any Zcu updates are sent to the linker. This allows the linker to fully parse all objects into a compact memory model, which is guaranteed to be complete when Zcu code is generated. This commit is not a complete implementation of all these goals; it is not even passing semantic analysis.
2025-01-05Added support for thin ltoTravis Lange
2024-12-23Merge pull request #22225 from alexrp/libc-linux-os-versionAlex Rønne Petersen
Attach minimum Linux versions to provided libcs + incorporate ABI in `VersionRange.default()`
2024-12-22compiler: Print more information when failing to provide libc.Alex Rønne Petersen
2024-12-17Merge pull request #22251 from alexrp/remove-cudaAndrew Kelley
`zig cc`: Remove broken CUDA C/C++ support.
2024-12-16compiler: introduce ZonGen and make `ast-check` run it for ZON inputsmlugg
Currently, `zig ast-check` fails on ZON files, because it tries to interpret the file as Zig source code. This commit introduces a new verification pass, `std.zig.ZonGen`, which applies to an AST in ZON mode. Like `AstGen`, this pass also converts the AST into a more helpful format. Rather than a sequence of instructions like `Zir`, the output format of `ZonGen` is a new datastructure called `Zoir`. This type is essentially a simpler form of AST, containing only the information required for consumers of ZON. It is also far more compact than `std.zig.Ast`, with the size generally being comparable to the size of the well-formatted source file. The emitted `Zoir` is currently not used aside from the `-t` option to `ast-check` which causes it to be dumped to stdout. However, in future, it can be used for comptime `@import` of ZON files, as well as for simpler handling of files like `build.zig.zon`, and even by other parts of the Zig Standard Library. Resolves: #22078
2024-12-15zig cc: Remove broken CUDA C/C++ support.Alex Rønne Petersen
2024-12-13zig fetch: support SHA-256 Git repositoriesIan Johnson
Closes #21888
2024-12-13Add compiler internals testsCarl Åstholm
There are several test decls inside `/src` that are not currently being tested and have bitrotted as a result. This commit revives those tests and adds the `test-compiler-internals` set of tests which tests everything reachable from `/src/main.zig`.
2024-12-11compiler: Improve the handling of unwind table levels.Alex Rønne Petersen
The goal here is to support both levels of unwind tables (sync and async) in zig cc and zig build. Previously, the LLVM backend always used async tables while zig cc was partially influenced by whatever was Clang's default.
2024-12-09Merge pull request #22157 from mlugg/astgen-error-lazyAndrew Kelley
compiler: allow semantic analysis of files with AstGen errors
2024-12-08compiler: Link libc when we're asked to link to an emulated wasi-libc library.Alex Rønne Petersen
2024-12-08compiler: Check for wasi-libc emulated libraries before libc libraries.Alex Rønne Petersen
This will become useful when we update wasi-libc and get the emulated libdl.
2024-12-06compiler: Remove warning about superfluous compiler-rt libraries.Alex Rønne Petersen
* This warning's wording is actually inaccurate when using the -fno-compiler-rt or -rtlib=none options. * It's not all that helpful; it's already understood that these libraries are part of the compiler, so printing a warning is just noise. In practice, this warning would always happen when building upstream musl, for example. * We don't warn when we satisfy -lunwind using our bundled libunwind either, or various libc libraries using our bundled libc, or when providing libc++, etc. So I really don't think we should be warning here either.
2024-12-06compiler: Recognize libgcc_s regardless of target ABI.Alex Rønne Petersen
The real libgcc_s is a compiler-provided library; it works just fine with both glibc and musl. There's no reason that I can see for this check to be limited to glibc-based targets.
2024-12-05compiler: incremental compilation fixesmlugg
The previous commit exposed some bugs in incremental compilation. This commit fixes those, and adds a little more logging for debugging incremental compilation. Also, allow `ast-check -t` to dump ZIR when there are non-fatal AstGen errors.
2024-12-05compiler: allow files with AstGen errors to undergo semantic analysismlugg
This commit enhances AstGen to introduce a form of error resilience which allows valid ZIR to be emitted even when AstGen errors occur. When a non-fatal AstGen error (e.g. `appendErrorNode`) occurs, ZIR generation is not affected; the error is added to `astgen.errors` and ultimately to the errors stored in `extra`, but that doesn't stop us getting valid ZIR. Fatal AstGen errors (e.g. `failNode`) are a bit trickier. These errors return `error.AnalysisFail`, which is propagated up the stack. In theory, any parent expression can catch this error and handle it, continuing ZIR generation whilst throwing away whatever was lost. For now, we only do this in one place: when creating declarations. If a call to `fnDecl`, `comptimeDecl`, `globalVarDecl`, etc, returns `error.AnalysisFail`, the `declaration` instruction is still created, but its body simply contains the new `extended(astgen_error())` instruction, which instructs Sema to terminate semantic analysis with a transitive error. This means that a fatal AstGen error causes the innermost declaration containing the error to fail, but the rest of the file remains intact. If a source file contains parse errors, or an `error.AnalysisFail` happens when lowering the top-level struct (e.g. there is an error in one of its fields, or a name has multiple declarations), then lowering for the entire file fails. Alongside the existing `Zir.hasCompileErrors` query, this commit introduces `Zir.loweringFailed`, which returns `true` only in this case. The end result here is that files with AstGen failures will almost always still emit valid ZIR, and hence can undergo semantic analysis on the parts of the file which are (from AstGen's perspective) valid. This is a noteworthy improvement to UX, but the main motivation here is actually incremental compilation. Previously, AstGen failures caused lots of semantic analysis work to be thrown out, because all `AnalUnit`s in the file required re-analysis so as to trigger necessary transitive failures and remove stored compile errors which would no longer make sense (because a fresh compilation of this code would not emit those errors, as the units those errors applied to would fail sooner due to referencing a failed file). Now, this case only applies when a file has severe top-level errors, which is far less common than something like having an unused variable. Lastly, this commit changes a few errors in `AstGen` to become fatal when they were previously non-fatal and vice versa. If there is still a reasonable way to continue AstGen and lower to ZIR after an error, it is non-fatal; otherwise, it is fatal. For instance, `comptime const`, while redundant syntax, has a clear meaning we can lower; on the other hand, using an undeclared identifer has no sane lowering, so must trigger a fatal error.
2024-11-26diversify "unable to spawn" failure messagesAndrew Kelley
to help understand where a spurious failure is occurring
2024-11-24dwarf: fix stepping through an inline loop containing one statementJacob Young
Previously, stepping from the single statement within the loop would always exit the loop because all of the code unrolled from the loop is associated with the same line and treated by the debugger as one line.
2024-11-16link: fix memory bugsJacob Young
2024-11-12compiler: un-jit `zig fmt`mlugg
This command being JITed leads to a substantially worse first-time user experience, since you have to wait for upwards of 20 seconds for `fmt.zig` to build. This is especially bad when your editor is configured to run `zig fmt` on save and does so in a blocking manner. As such, it makes sense from a usability perspective to not JIT this particular command.
2024-11-05Compilation: Move no_builtin to Package.Module.Alex Rønne Petersen
This option, by its very nature, needs to be attached to a module. If it isn't, the code in a module could break at random when compiled into an application that doesn't have this option set. After this change, skip_linker_dependencies no longer implies no_builtin in the LLVM backend.
2024-10-31compiler: remove anonymous struct types, unify all tuplesmlugg
This commit reworks how anonymous struct literals and tuples work. Previously, an untyped anonymous struct literal (e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type", which is a special kind of struct which coerces using structural equivalence. This mechanism was a holdover from before we used RLS / result types as the primary mechanism of type inference. This commit changes the language so that the type assigned here is a "normal" struct type. It uses a form of equivalence based on the AST node and the type's structure, much like a reified (`@Type`) type. Additionally, tuples have been simplified. The distinction between "simple" and "complex" tuple types is eliminated. All tuples, even those explicitly declared using `struct { ... }` syntax, use structural equivalence, and do not undergo staged type resolution. Tuples are very restricted: they cannot have non-`auto` layouts, cannot have aligned fields, and cannot have default values with the exception of `comptime` fields. Tuples currently do not have optimized layout, but this can be changed in the future. This change simplifies the language, and fixes some problematic coercions through pointers which led to unintuitive behavior. Resolves: #16865
2024-10-29CLI: don't warn on missing host-detected directoriesAndrew Kelley