With the old logic, it was possible for a bunch of processes to queue up
to update a cache entry, and then each to do so one at a time. Now, it
rechecks whether there still a cache miss or another process has
completed the work in the interim.
When checking a cache entry with no input files for a hit, if
`createFile` returned `error.WouldBlock` we would forget about the fact
that the file has been created, and all future checks will assume that a
cache hit has happened, even though one never has or does, leading to
rare `FileNotFound` errors trying the access the protected files.
This fix works by writing an extra byte to the manifest file to
distinguish hits and misses when there no input files to write.
This introduces a parallel set of functions to the std.mem.indexOfAny
functions. They simply invert the logic, yielding the first/last index
which is *not* contained in the "values" slice.
Inverting this logic is useful when you are attempting to determine the
initial span which contains only characters in a particular set.
* Document the `indexOfNone` family.
These descriptions are somewhat brief, but the functions themselves are
also simple enough to describe in such a way.
```
$ cat overflow.zig
test {
var a: [1]u65535 = undefined;
_ = a;
}
$ zig-out/bin/zig test overflow.zig
thread 290266 panic: integer overflow
zig/src/type.zig:3604:55: 0xada43d in intAbiAlignment (zig)
std.math.ceilPowerOfTwoPromote(u16, (bits + 7) / 8),
^
zig/src/type.zig:3598:42: 0xadd4ea in intAbiSize (zig)
const alignment = intAbiAlignment(bits, target);
^
zig/src/type.zig:3500:61: 0x92be91 in abiSizeAdvanced (zig)
return AbiSizeAdvanced{ .scalar = intAbiSize(bits, target) };
^
zig/src/type.zig:3385:62: 0x928933 in abiSizeAdvanced (zig)
switch (try payload.elem_type.abiSizeAdvanced(target, strat)) {
^
zig/src/type.zig:3268:32: 0x92c012 in abiSize (zig)
return (abiSizeAdvanced(ty, target, .eager) catch unreachable).scalar;
^
```
This is only noticed in a debug build of zig and silently does the wrong
thing and overflows in release builds.
This happened to `[x]u65529` and above because of the ` + 7` on a `u16`.
