The problem was that types of non-anytype parameters were being included
as part of the check to see if generic function instantiations were
equal. Now, Module.Fn additionally stores the information for whether each
parameter is anytype or not. `generic_poison` cannot be used to signal
this because the type is still needed for comptime arguments; in such
case the type will not be present in the newly generated function
prototype.
This presented one additional challenge: we need to compare equality of
two values where one of them is post-coercion and the other is not. So
we make some minor adjustments to `Type.eql` to support this. I think
this small complexity tradeoff is worth it because it means the compiler
does much less work on the hot path that a generic function is called
and there is already an existing matching instantiation.
closes#11146
Fix to call siftDown on the removed index instead of always on index 0.
Updated test to a test that fails before and passes now.
PriorityDequeue does not have this issue.
Looks like d3f87f8ac01039722197a13a12342fc747a90567 fixed the standard cases of dir renaming, but the edge cases (renaming onto an existing empty/non-empty directory) are still behaving differently than on non-Windows.
Sometimes we will want to generate debug info for a constant that
has been lowered to memory and not copied anywhere else. For this
we will need to defer resolution on PIE platforms until all locals
(including GOT entries) have been allocated.
Prior to this, Liveness encoded `asm`, `call`, and `aggregate_init` with
a single 32-bit integer, allowing up to 35 operands (3 are provided by
the regular tomb_bits). However, the Zig language allows function calls
with more than 35 arguments, inline assembly with more than 35 inputs,
and anonymous tuples with more than 35 elements.
The new encoding stores an index to the extra array instead of the bits
directly, and then as many extra elements as needed to encode all the
operands. The MSB is used as a flag to tell which element is the last
one, allowing for 31 bits per element.
Prior to this, print_air did not bother correctly printing tombstones
for these instructions; now it does.
In addition to updating the BigTomb iteration logic in the machine code
backends, this commit extracts the common logic into the Liveness namespace.
These defines are present on some FreeBSD systems, regardless of
whether the system is big- or little- endian. This was causing the
FreeBSD CI to be incorrectly flagged as big-endian.
Resolves https://github.com/ziglang/zig/issues/11391
Also split the Dir.rename on directories test into 3 tests:
- General rename of a directory
- Rename of a directory onto an existing empty directory
- Rename of a directory onto an existing non-empty directory
The only new case is the rename onto an existing empty directory, but splitting the tests this way made them much more understandable.
Currently transitive system library dependencies are always linked using
linkSystemLibrary() and therefore pkg-config even if they were
originally specified with linkSystemLibraryName() instead. This causes
problems in practice for projects needing total control over exactly
what library is linked, such as the mach game engine.
This is fixed by keeping track of whether libraries are to be linked
with pkg-config or not and holding off on actually running pkg-config
until after transitive dependency resolution in LibExeObjStep.make().
This also fixes a separate issue with the pkg-config handling that could
cause partial application of pkg-config flags if the first part of the
pkg-config output parses correctly but there is an error later on. This
error isn't always fatal as we fall back to a plain -lfoo in the case of
linkSystemLibrary().
Previously it would fail as `renameW` do not ever fail with
`PathAlreadyExists`.
As a workaround we check for dest dir existence before rename
on Windows.
Compile error test cases can now be given as a sequence of files:
- "foo.1.zig"
- "foo.2.zig"
- "foo.3.zig"
- etc.
This sequence of files is tested as incremental compilation updates to a
single "foo.zig" source file.
To help avoid mistakes, we enforce strict ordering for these files.
"foo.zig" cannot co-exist with "foo.X.zig", the sequence must include
"foo.1.zig", and no numbers may be skipped.
In 008b0ec5e58fc7e31f3b989868a7d1ea4df3f41d the `std.Thread.Mutex` API was changed
from `acquire` and `release` to `lock` and `unlock`. `std.event.Lock` still uses `acquire`
and `release`. `std.event.WaitGroup` is using `std.Thread.Mutex` and was not updated to use
`lock` and `unlock`, and so compilation failed prior to this commit.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
* std: add Thread.Condition.timedWait
I needed the equivalent of `std::condition_variable::wait_for`, but it's missing in std.
This PR adds an implementation, following the status quo of using std.os.CLOCK.REALTIME in the pthread case (i.e. Futex)
A follow-up patch moving futex/condition stuff to monotonic clocks where available seems like a good idea.
This would involve conditionally exposing more functions and constants through std.c and std.os.
For instance, Chromium picks `pthread_cond_timedwait_relative_np` on macOS and `clock_gettime(CLOCK_MONOTONIC...)` on BSD's.
Tested on Windows 11, macOS 12.2.1 and Linux (with/without libc)
* Sleep in the single threaded case, handle timeout overflow in the Windows case and address a race condition in the AtomicCondition case.
This causes false positive "foo depends on itself" errors. Prior to some
recent enhancements, this type resolution was needed, however, we now
have a more sophisticated type resolution mechanism that fully
resolves types for the backend, but only after the Decl is fully
analyzed, avoiding dependency loops.
This is the x25519 counterpart to `edwards25519.clearCofactor()`.
It is useful to check for low-order points in protocols where it matters and where clamping cannot work, such as PAKEs.
