All four of these can be represented in fewer characters with
expressions, which will be guaranteed to happen at compile-time, and
have the same or better precision.
The other math constants here which depend on function calls could be
similarly removed if and when #425 is solved. However I left them for
now since Zig does not eagerly evaluate functions with comptime parameters.
- on Windows use first found env var { "Path", "PATH" }
Bug Description: `build test` results in the following error on in
a msys64 shell with "PATH" env var instead of "Path":
error while loading shared libraries: mathtest.dll:
cannot open shared object file: No such file or directory
* Implements #3768. This is a sweeping breaking change that requires
many (trivial) edits to Zig source code. Array values no longer
coerced to slices; however one may use `&` to obtain a reference to
an array value, which may then be coerced to a slice.
* Adds `IrInstruction::dump`, for debugging purposes. It's useful to
call to inspect the instruction when debugging Zig IR.
* Fixes bugs with result location semantics. See the new behavior test
cases, and compile error test cases.
* Fixes bugs with `@typeInfo` not properly resolving const values.
* Behavior tests are passing but std lib tests are not yet. There
is more work to do before merging this branch.
The actual desired access mask in this case seems quite confusing and badly documented. The previous combination of `GENERIC_READ` and `SYNCHRONIZE` seems both illegal and redundant according to the [`ntifs.h` documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile), which specifies that `GENERIC_READ` should not be used for directories and includes `SYNCHRONIZE`. `winnt.h` contains a number of relevant-sounding flags such as `FILE_ADD_FILE`, `FILE_ADD_SUBDIRECTORY`, and `FILE_DELETE_CHILD` that do not show up in documentation at all. These are equal in value to file-specific flags that are documented as flags you should not specify when opening a directory.
The Windows-inspired nomenclature of "List" and "Traverse" was chosen over POSIX-style "Read" and "Path" (from `O_PATH`) for clarity. Using "Path" makes it look like the function is manipulating strings, and the generic "Read" ending isn't useful when there is no generic read method. Even in implementation details, `read` is never used.
Actual exploitation of the difference between the two functions will come in a later commit.
