Some users are hitting this limit. I think it's primarily due to not
deduplicating (solved in the previous commit) but this seems like a
better limit regardless.
The zig way is to let the compiler provide errors, rather than trying to
implement the compiler in the standard library.
I played around with this and found the compile errors to be easier to
comprehend without this logic.
1. Entirely rewrote frexp with generics, reducing the implementation to a single function and enabling parameters of types f80 and f16
2. Expanded upon the tests, making them more descriptive and comprehensive, and automatically generating the test bodies for each floating point type
3. Added a doctest for frexp
Symmetry with parse_float and to hide the implementation from the user.
Additionally, we expose the entire namespace and provide some aliases so
everything is available to a user.
Closes#19366
Stores the original ref as a query parameter in the URL so that it is
possible to automatically check the upstream if there are any newer
commits.
Also adds a flag which opts-out of the new behaivour, restoring the old.
When the slice-by-length start position is runtime-known, it is likely
protected by a runtime-known condition and therefore a compile error is
less appropriate than a runtime panic check.
This is demonstrated in the json code that was updated and then reverted
in this commit.
When #3806 is implemented, this decision can be reassessed.
Revert "std: work around compiler unable to evaluate condition at compile time"
Revert "frontend: comptime array slice-by-length OOB detection"
This reverts commit 7741aca96c8cc6df7e8c4bd10ada741d6a3ffb9d.
This reverts commit 2583b389eaf5f7aaa0eb79b51126506c1e172d15.
netbsd fix:
- `Futex.zig:542:56: error: expected error union type, found 'c_int'`
openbsd fix:
- `emutls.zig:10:21: error: root struct of file 'os' has no member named 'abort'`
- `Thread.zig:627:22: error: expected 6 argument(s), found 5`
This was a mistake from day one. This is the wrong abstraction layer to
do this in.
My alternate plan for this is to make all I/O operations require an IO
interface parameter, similar to how allocations require an Allocator
interface parameter today.
