aboutsummaryrefslogtreecommitdiff
path: root/src/Compilation.zig
AgeCommit message (Collapse)Author
2024-07-23Merge pull request #20725 from ziglang/fuzzAndrew Kelley
initial support for integrated fuzzing
2024-07-22Compilation: fix regression in addCCArgsAndrew Kelley
`-fno-sanitize=function` must come after `-fsanitize=undefined` or it has no effect.
2024-07-22initial support for integrated fuzzingAndrew Kelley
* Add the `-ffuzz` and `-fno-fuzz` CLI arguments. * Detect fuzz testing flags from zig cc. * Set the correct clang flags when fuzz testing is requested. It can be combined with TSAN and UBSAN. * Compilation: build fuzzer library when needed which is currently an empty zig file. * Add optforfuzzing to every function in the llvm backend for modules that have requested fuzzing. * In ZigLLVMTargetMachineEmitToFile, add the optimization passes for sanitizer coverage. * std.mem.eql uses a naive implementation optimized for fuzzing when builtin.fuzz is true. Tracked by #20702
2024-07-22macho: redo input file parsing in prep for multithreadingJakub Konka
2024-07-20Merge pull request #20688 from ziglang/incr-testAndrew Kelley
introduce a new tool for testing incremental compilation
2024-07-20dev: fix llvm backend checksJacob Young
2024-07-20add std.fmt.hexAndrew Kelley
converts an unsigned integer into an array
2024-07-19dev: introduce dev environments that enable compiler feature setsJacob Young
2024-07-15update some Module references to Zcu insteadAndrew Kelley
I ended up reverting my real change, so here's a consolation prize instead.
2024-07-15frontend: move updateZirRefs to be single-threadedAndrew Kelley
for simplicity's sake. This makes it O(M) instead of O(N*M) where N is tracked insts and M is number of changed source files.
2024-07-14frontend: add -fincremental, -fno-incremental flagAndrew Kelley
Remove --debug-incremental This flag is also added to the build system. Importantly, this tells Compile step whether or not to keep the compiler running between rebuilds. It defaults off because it is currently crashing zirUpdateRefs.
2024-07-14make zig compiler processes live across rebuildsAndrew Kelley
Changes the `make` function signature to take an options struct, which additionally includes `watch: bool`. I intentionally am not exposing this information to configure phase logic. Also adds global zig cache to the compiler cache prefixes. Closes #20600
2024-07-14Merge pull request #20593 from jacobly0/more-racesAndrew Kelley
InternPool: fix more races
2024-07-13frontend: report correct paths for C objectsAndrew Kelley
oops, the src_path field of CObject is not relative to the module owner's root directory.
2024-07-13Compilation: restore `saveState`Jacob Young
2024-07-13Compilation: introduce work stages for better work distributionJacob Young
2024-07-13InternPool: add and use a mutate mutex for each listJacob Young
This allows the mutate mutex to only be locked during actual grows, which are rare. For the lists that didn't previously have a mutex, this change has little effect since grows are rare and there is zero contention on a mutex that is only ever locked by one thread. This change allows `extra` to be mutated without racing with a grow.
2024-07-12Compilation: fix rebase conflictAndrew Kelley
2024-07-12frontend: add file system inputs for incremental cache modeAndrew Kelley
These are also used for whole cache mode in the case that any compile errors are emitted.
2024-07-12integrate Compile steps with file watchingAndrew Kelley
Updates the build runner to unconditionally require a zig lib directory parameter. This parameter is needed in order to correctly understand file system inputs from zig compiler subprocesses, since they will refer to "the zig lib directory", and the build runner needs to place file system watches on directories in there. The build runner's fanotify file watching implementation now accounts for when two or more Cache.Path instances compare unequal but ultimately refer to the same directory in the file system. Breaking change: std.Build no longer has a zig_lib_dir field. Instead, there is the Graph zig_lib_directory field, and individual Compile steps can still have their zig lib directories overridden. I think this is unlikely to break anyone's build in practice. The compiler now sends a "file_system_inputs" message to the build runner which shares the full set of files that were added to the cache system with the build system, so that the build runner can watch properly and redo the Compile step. This is implemented for whole cache mode but not yet for incremental cache mode.
2024-07-10Compilation: fix leakJacob Young
2024-07-10InternPool: make `global_error_set` thread-safeJacob Young
2024-07-10InternPool: make `tracked_insts` thread-safeJacob Young
2024-07-10InternPool: make `files` more thread-safeJacob Young
2024-07-10InternPool: add `FileIndex` to `*File` mappingJacob Young
2024-07-08Compilation: put supported codegen backends on a separate threadJacob Young
(There are no supported backends.)
2024-07-07InternPool: implement and use thread-safe list for extra and limbsJacob Young
2024-07-07InternPool: implement and use thread-safe list for itemsJacob Young
2024-07-07InternPool: implement and use thread-safe list for stringsJacob Young
2024-07-07InternPool: implement thread-safe hash mapJacob Young
2024-07-07Zcu: pass `PerThread` to intern pool string functionsJacob Young
2024-07-07Zcu: introduce `PerThread` and pass to all the functionsJacob Young
2024-07-04frontend: TrackedInst stores FileIndex instead of path digestAndrew Kelley
The purpose of using path digest was to reference a file in a serializable manner. Now that there is a stable index associated with files, it is a superior way to accomplish that goal, since removes one layer of indirection, and makes TrackedInst 8 bytes instead of 20. The saved Zig Compiler State file for "hello world" goes from 1.3M to 1.2M with this change.
2024-07-04Zcu: extract permanent state from FileAndrew Kelley
Primarily, this commit removes 2 fields from File, relying on the data being stored in the `files` field, with the key as the path digest, and the value as the struct decl corresponding to the File. This table is serialized into the compiler state that survives between incremental updates. Meanwhile, the File struct remains ephemeral data that can be reconstructed the first time it is needed by the compiler process, as well as operated on by independent worker threads. A key outcome of this commit is that there is now a stable index that can be used to refer to a File. This will be needed when serializing error messages to survive incremental compilation updates.
2024-07-04Compilation: don't give len=0 bufs to pwritevAndrew Kelley
The OS returns EFAULT for undefined pointers, even when len=0.
2024-07-04Merge pull request #20494 from mlugg/the-great-decl-splitAndrew Kelley
refactors ad infinitum
2024-07-04Compilation: rename tsan_static_lib to tsan_libJakub Konka
2024-07-04cbe: fix for export changesJacob Young
2024-07-04compiler: rework type resolution, fully resolve all typesmlugg
I'm so sorry. This commit was just meant to be making all types fully resolve by queueing resolution at the moment of their creation. Unfortunately, a lot of dominoes ended up falling. Here's what happened: * I added a work queue job to fully resolve a type. * I realised that from here we could eliminate `Sema.types_to_resolve` if we made function codegen a separate job. This is desirable for simplicity of both spec and implementation. * This led to a new AIR traversal to detect whether any required type is unresolved. If a type in the AIR failed to resolve, then we can't run codegen. * Because full type resolution now occurs by the work queue job, a bug was exposed whereby error messages for type resolution were associated with the wrong `Decl`, resulting in duplicate error messages when the type was also resolved "by" its owner `Decl` (which really *all* resolution should be done on). * A correct fix for this requires using a different `Sema` when performing type resolution: we need a `Sema` owned by the type. Also note that this fix is necessary for incremental compilation. * This means a whole bunch of functions no longer need to take `Sema`s. * First-order effects: `resolveTypeFields`, `resolveTypeLayout`, etc * Second-order effects: `Type.abiAlignmentAdvanced`, `Value.orderAgainstZeroAdvanced`, etc The end result of this is, in short, a more correct compiler and a simpler language specification. This regressed a few error notes in the test cases, but nothing that seems worth blocking this change. Oh, also, I ripped out the old code in `test/src/Cases.zig` which introduced a dependency on `Compilation`. This dependency was problematic at best, and this code has been unused for a while. When we re-enable incremental test cases, we must rewrite their executor to use the compiler server protocol.
2024-07-04compiler: type.zig -> Type.zigmlugg
2024-07-04Zcu: store `LazySrcLoc` in error messagesmlugg
This change modifies `Zcu.ErrorMsg` to store a `Zcu.LazySrcLoc` rather than a `Zcu.SrcLoc`. Everything else is dominoes. The reason for this change is incremental compilation. If a failed `AnalUnit` is up-to-date on an update, we want to re-use the old error messages. However, the file containing the error location may have been modified, and `SrcLoc` cannot survive such a modification. `LazySrcLoc` is designed to be correct across incremental updates. Therefore, we defer source location resolution until `Compilation` gathers the compile errors into the `ErrorBundle`.
2024-07-04Zcu: rework reference tracesmlugg
Previously, `reference_table` mapped from a `Decl` being referenced to the `Decl` that performed the reference. This is convenient for constructing error messages, but problematic for incremental compilation. This is because on an incremental update, we want to efficiently remove all references triggered by an `AnalUnit` which is being re-analyzed. For this reason, `reference_table` now maps the other way: from the `AnalUnit` *performing* the reference, to the `AnalUnit` whose analysis was triggered. As a general rule, any call to any of the following functions should be preceded by a call to `Sema.addReferenceEntry`: * `Zcu.ensureDeclAnalyzed` * `Sema.ensureDeclAnalyzed` * `Zcu.ensureFuncBodyAnalyzed` * `Zcu.ensureFuncBodyAnalysisQueued` This is not just important for error messages, but also more fundamentally for incremental compilation. When an incremental update occurs, we must determine whether any `AnalUnit` has become unreferenced: in this case, we should ignore its associated error messages, and perhaps even remove it from the binary. For this reason, we no longer store only one reference to every `AnalUnit`, but every reference. At the end of an update, `Zcu.resolveReferences` will construct the reverse mapping, and as such identify which `AnalUnit`s are still referenced. The current implementation doesn't quite do what we need for incremental compilation here, but the framework is in place. Note that `Zcu.resolveReferences` does constitute a non-trivial amount of work on every incremental update. However, for incremental compilation, this work -- which will effectively be a graph traversal over all `AnalUnit` references -- seems strictly necessary. At the moment, this work is only done if the `Zcu` has any errors, when collecting them into the final `ErrorBundle`. An unsolved problem here is how to represent inline function calls in the reference trace. If `foo` performs an inline call to `bar` which references `qux`, then ideally, `bar` would be shown on the reference trace between `foo` and `qux`, but this is not currently the case. The solution here is probably for `Zcu.Reference` to store information about the source locations of active inline calls betweeen the referencer and its reference.
2024-07-04Zcu: key compile errors on `AnalUnit` where appropriatemlugg
This change seeks to more appropriately model the way semantic analysis works by drawing a more clear line between errors emitted by analyzing a `Decl` (in future a `Cau`) and errors emitted by analyzing a runtime function. This does change a few compile errors surrounding compile logs by adding more "also here" notes. The new notes are more technically correct, but perhaps not so helpful. They're not doing enough harm for me to put extensive thought into this for now.
2024-07-04compiler: rename AnalSubject to AnalUnitmlugg
I meant to call it this originally, I just got mixed up -- sorry!
2024-07-04tsan: build dynamic library on Apple platformsJakub Konka
2024-07-03Compilation: pass libc include directories when compiling assembly_with_cppKrzysztof Wolicki
2024-06-26InternPool: rename `Depender` to `AnalSubject`mlugg
This is essentially just a rename. I also changed the representation of `AnalSubject` to use a `packed struct` rather than a non-exhaustive enum, but that change is relatively trivial.
2024-06-22rename src/Module.zig to src/Zcu.zigAndrew Kelley
This patch is a pure rename plus only changing the file path in `@import` sites, so it is expected to not create version control conflicts, even when rebasing.
2024-06-15Zcu: rework source locationsmlugg
`LazySrcLoc` now stores a reference to the "base AST node" to which it is relative. The previous tagged union is `LazySrcLoc.Offset`. To make working with this structure convenient, `Sema.Block` contains a convenience `src` method which takes an `Offset` and returns a `LazySrcLoc`. The "base node" of a source location is no longer given by a `Decl`, but rather a `TrackedInst` representing either a `declaration`, `struct_decl`, `union_decl`, `enum_decl`, or `opaque_decl`. This is a more appropriate model, and removes an unnecessary responsibility from `Decl` in preparation for the upcoming refactor which will split it into `Nav` and `Cau`. As a part of these `Decl` reworks, the `src_node` field is eliminated. This change aids incremental compilation, and simplifies `Decl`. In some cases -- particularly in backends -- the source location of a declaration is desired. This was previously `Decl.srcLoc` and worked for any `Decl`. Now, it is `Decl.navSrcLoc` in reference to the upcoming refactor, since the set of `Decl`s this works for precisely corresponds to what will in future become a `Nav` -- that is, source-level declarations and generic function instantiations, but *not* type owner Decls. This commit introduces more tags to `LazySrcLoc.Offset` so as to eliminate the concept of `error.NeededSourceLocation`. Now, `.unneeded` should only be used to assert that an error path is unreachable. In the future, uses of `.unneeded` can probably be replaced with `undefined`. The `src_decl` field of `Sema.Block` no longer has a role in type resolution. Its main remaining purpose is to handle namespacing of type names. It will be eliminated entirely in a future commit to remove another undue responsibility from `Decl`. It is worth noting that in future, the `Zcu.SrcLoc` type should probably be eliminated entirely in favour of storing `Zcu.LazySrcLoc` values. This is because `Zcu.SrcLoc` is not valid across incremental updates, and we want to be able to reuse error messages from previous updates even if the source file in question changed. The error reporting logic should instead simply resolve the location from the `LazySrcLoc` on the fly.
2024-05-27Compilation: fix sub-compilations given wrong progress nodeAndrew Kelley