[pull] master from ziglang:master #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
There is no evidence that these operating systems support pure Thumb, not even just in userland.
These are no longer supported.
Illumos dropped support for SPARC many years ago.
This allows emitting object files for s390x-zos (GOFF) and powerpc(64)-aix (XCOFF). Note that GOFF emission in LLVM is still being worked on upstream for LLVM 21; the resulting object files are useless right now. Also, -fstrip is required, or LLVM will SIGSEGV during DWARF emission.
Aside from adding comments to document the logic in `Cache.Manifest.hit` better, this commit fixes two serious bugs. The first, spotted by Andrew, is that when upgrading from a shared to an exclusive lock on the manifest file, we do not seek it back to the start. This is a simple fix. The second is more subtle, and has to do with the computation of file digests. Broadly speaking, the goal of the main loop in `hit` is to iterate the files listed in the manifest file, and check if they've changed, based on stat and a file hash. While doing this, the `bin_digest` field of `std.Build.Cache.File`, which is initially `undefined`, is populated for all files, either straight from the manifest (if the stat matches) or recomputed from the file on-disk. This file digest is then used to update `man.hash.hasher`, which is building the final hash used as, for instance, the output directory name when the compiler emits into the cache directory. When `hit` returns a cache miss, it is expected that `man.hash.hasher` includes the digests of all "initial files"; that is, those which have been already added with e.g. `addFilePath`, but not those which will later be added with `addFilePost` (even though the manifest file has told us about some such files). Previously, `hit` was using the `unhit` function to do this in a few cases. However, this is incorrect, because `hit` assumes that all files already have their `bin_digest` field populated; this function is only valid to call *after* `hit` returns. Instead, we need to actually compute the hashes which haven't yet been populated. Even if this logic has been working, there was still a bug here, because we called `unhit` when upgrading from a shared to an exclusive lock, writing the (potentially `undefined`) file digests, but the loop itself writes the file digests *again*! All in all, the hashing logic here was actually incredibly broken. I've taken the opportunity to restructure this section of the code into what I think is a more readable format. A new function, `hitWithCurrentLock`, uses the open manifest file to try and find a cache hit. It returns a tagged union which, in the miss case, tells the caller (`hit`) how many files already have their hash populated. This avoids redundant work recomputing the same hash multiple times in situations where the lock needs upgrading. This also eliminates the outer loop from `hit`, which was a little confusing because it iterated no more than twice! The bugs fixed here could manifest in several different ways depending on how contended file locks were satisfied. Most notably, on a cache miss, the Zig compiler might have written the compilation output to the incorrect directory (because it incorrectly constructed a hash using `undefined` or repeated file digests), resulting in all future hits on this manifest causing `error.FileNotFound`. This is #23110. I have been able to reproduce #23110 on `master`, and have not been able to after this commit, so I am relatively sure this commit resolves that issue. Resolves: #23110
Rename `trimLeft` to `trimStart`, and `trimRight` to `trimEnd`. `trimLeft` and `trimRight` functions remain as deprecated aliases for these new names.
LLD doesn't support these yet. Doing this hack will at least allow basic experimentation for these targets.
LLVM can only produce assembly files for this target currently.
These backends are completely unusable at the moment; they can produce neither assembly files nor object files. So give a nicer error when users try to use them.
…r when a read or write is attempted on a disconnected virtual com port
add `@memmove` builtin
The last Intel Quark MCU was released in 2015. Quark was announced to be EOL in 2019, and stopped shipping entirely in 2022. The OS tag was only meaningful for Intel's weird fork of Linux 3.8.7 with a special ABI that differs from the regular i386 System V ABI; beyond that, the CPU itself is just a plain old P54C (i586). We of course keep support for the CPU itself, just not Intel's Linux fork.
Turns out the backend currently never emits a non-static initializer, but the handling is kept in case it is needed again in the future.
`writeCValue` already emits a cast; including another here is, in fact, invalid, and emits errors under MSVC. Probably this code was originally added to work around the incorrect `.Initializer` location which was fixed in the previous commit.
`link`: Stub out GOFF/XCOFF linker code based on LLVM
Nothing interesting here; literally just the bare minimum so I can work on this on and off in a branch without worrying about merge conflicts in the non-backend code.
* libc: implement common `abs` for various integer sizes * libc: move imaxabs to inttypes.zig and don't use cInclude * libc: delete `fabs` c implementations because already implemented in compiler_rt * libc: export functions depending on the target libc Previously all the functions that were exported were handled equally, though some may exist and some not inside the same file. Moving the checks inside the file allows handling different functions differently * remove empty ifs in inttypes Co-authored-by: Alex Rønne Petersen <[email protected]> * remove empty ifs in stdlib Co-authored-by: Alex Rønne Petersen <[email protected]> * libc: use `@abs` for the absolute value calculation --------- Co-authored-by: Alex Rønne Petersen <[email protected]>
Right now, if you override the build root with `--build-root`, then `Run` steps can fail to execute because of incorrect path handling in the compiler: `std.process.Child` gets a cwd-relative path, but also has its cwd set to the build root. The latter behavior is really weird; it doesn't match my expectations, nor does it match how we spawn child `zig` processes. So, this commit makes the child process inherit the build runner's cwd, as `LazyPath.getPath2` *expects* it to. After investigating, this behavior dates all the way back to 2017; it was introduced in 4543413. So, there isn't any clear/documented reason for this; it should be safe to revert, since under the modern `LazyPath` system it is strictly a bug AFAICT.
Since we need testing for passing `--build-file` and `--cache-dir` together anyway, use it to test the disabled build options test.
Leftover from 76d525f.
std.Build.Step.Run: inherit build runner cwd
This was an unintentional regression in 23c8175 which meant that backwards-incompatible ZIR changes would have caused compiler crashes if old caches were present.
37a9a4e accidentally turned paths `b/[hash]/` into `b[hash]/` in the global cache. This doesn't technically break anything, but it pollutes the global cache directory. Sorry about that one!
OpenBSD -current grew EVFILT_USER. See commit message [1] and and current sys/event.h [2] Also EVFILT_DEVICE was missing. Closes #23930 [1]: https://marc.info/?l=openbsd-cvs&m=174686993115485&w=2 [2]: https://codeberg.org/OpenBSD/src/src/branch/master/sys/sys/event.h
The doc comment here agreed with the implementation, but not with *any* `Step` which populates a `GeneratedFile`, where they are treated as cwd-relative. This is the obvious correct choice, because these paths usually come from joining onto a cache root, and those are cwd-relative if not absolute. This was a pre-existing bug, but #23836 caused it to trigger more often, because the compiler now commonly passes the local cache directory to the build runner process as a relative path where it was previously an absolute path. Resolves: #23954
GitHub have introduced an absolutely baffling feature where users can use Copilot to take their simple explanation of a bug, and reword it into a multi-paragraph monologue with no interesting details and added false information, while also potentially ignoring issue templates. So far, GitHub has not provided a way to block this feature at the repository or organisation level, so for now, this is the only way to prevent users from filing LLM-generated slop. Related: https://github.com/orgs/community/discussions/159749
Reduced number of runners from 9 to 6. This number is the total physical memory (251G) divided by the number of runners we have active (6). see previous commit 5b9e528
In a compiler built with debug extensions, pass `--debug-incremental` to spawn the "incremental debug server". This is a TCP server exposing a REPL which allows querying a bunch of compiler state, some of which is stored only when that flag is passed. Eventually, this will probably move into `std.zig.Server`/`std.zig.Client`, but this is easier to work with right now. The easiest way to interact with the server is `telnet`.
In the case where a declaration has no type annotation, the interaction between resolution of `nav_ty` and `nav_val` is a little fiddly because of the fact that resolving `nav_val` actually implicitly resolves the type as well. This means `nav_ty` never gets an opporunity to mark its dependency on the `nav_val`. So, `ensureNavValUpToDate` needs to be the one to do it. It can't do it too early, though; otherwise, our marking of dependees as out-of-date/up-to-date will go wrong. Resolves: #23959
spirv: unroll all vector operations
incremental: bugfix (and a debugging feature that helped me do that bugfix)
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.
Because we don't pass -fqemu and -fwasmtime on aarch64-linux, we're just spending a bunch of time compiling all these module tests only to not even run them. x86_64-linux already covers both compiling and running them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )