mirror of
https://codeberg.org/ziglang/zig.git
synced 2025-12-06 05:44:20 +00:00
37a9a4e0f1
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 |
||
|---|---|---|
| .. | ||
| compile_errors | ||
| llvm | ||
| run_translated_c | ||
| safety | ||
| translate_c | ||
| address_of_extern_var_as_const.zig | ||
| ambiguous_reference.zig | ||
| array_in_anon_struct.zig | ||
| bad_inferred_variable_type.zig | ||
| comparison_of_non-tagged_union_and_enum_literal.zig | ||
| compile_error.zig | ||
| comptime_aggregate_print.zig | ||
| decl_value_arena.zig | ||
| error_in_nested_declaration.zig | ||
| exit.zig | ||
| f32_passed_to_variadic_fn.zig | ||
| float_mode_optimized_reduce.zig | ||
| fn_typeinfo_passed_to_comptime_fn.zig | ||
| function_pointers.zig | ||
| function_redeclaration.zig | ||
| global_variable_redeclaration.zig | ||
| inherit_want_safety.zig | ||
| inner_func_accessing_outer_var.zig | ||
| large_add_function.zig | ||
| maximum_sized_integer_literal.zig | ||
| no_compile_panic_for_unchecked_arith.zig | ||
| non_leaf_functions.zig | ||
| passing_u0_to_function.zig | ||
| pic_freestanding.zig | ||
| pic_linux.zig | ||
| pie_freestanding.zig | ||
| pie_linux.zig | ||
| print_u32s.zig | ||
| README.md | ||
| recursive_fibonacci.zig | ||
| returning_undefined_sentinel_terminated_const_u8_slice.zig | ||
| returns_in_try.zig | ||
| runtime_bitwise_and.zig | ||
| runtime_bitwise_or.zig | ||
| save_function_return_values_in_callee_preserved_register.zig | ||
| setting_an_address_space_on_a_local_variable.zig | ||
| spirv_mergable_pointers.zig | ||
| tail_call_noreturn.zig | ||
| taking_pointer_of_global_tagged_union.zig | ||
| try_in_comptime_in_struct_in_test.zig | ||
| union_unresolved_layout.zig | ||
| unused_vars.zig | ||
Test Case Quick Reference
Use comments at the end of the file to indicate metadata about the test case. Here are examples of different kinds of tests:
Compile Error Test
If you want it to be run with zig test and match expected error messages:
// error
// is_test=true
//
// :4:13: error: 'try' outside function scope
Execution
This will do zig run on the code and expect exit code 0.
// run
Translate-c
If you want to test translating C code to Zig use translate-c:
// translate-c
// c_frontend=aro,clang
// target=x86_64-linux
//
// pub const foo = 1;
// pub const immediately_after_foo = 2;
//
// pub const somewhere_else_in_the_file = 3:
Run Translated C
If you want to test translating C code to Zig and then executing it use run-translated-c:
// run-translated-c
// c_frontend=aro,clang
// target=x86_64-linux
//
// Hello world!
Incremental Compilation
Make multiple files that have ".", and then an integer, before the ".zig" extension, like this:
hello.0.zig
hello.1.zig
hello.2.zig
Each file can be a different kind of test, such as expecting compile errors, or expecting to be run and exit(0). The test harness will use these to simulate incremental compilation.
At the time of writing there is no way to specify multiple files being changed as part of an update.
Subdirectories
Subdirectories do not have any semantic meaning but they can be used for organization since the test harness will recurse into them. The full directory path will be prepended as a prefix on the test case name.
Limiting which Backends and Targets are Tested
// run
// backend=stage2,llvm
// target=x86_64-linux,x86_64-macos
Possible backends are:
stage1: equivalent to-fstage1.stage2: equivalent to passing-fno-stage1 -fno-LLVM.llvm: equivalent to-fLLVM -fno-stage1.