Total bytes used in stage1 std lib tests:
3.418 -> 3.198 GiB (saving 225 MiB)
There's still this from pass 1 not getting freed:
Const: 6909049 items, 72 bytes each, total 474.407 MiB
This is due to 2 things hanging on to references to IrAnalyze pointers:
* ZigVar->owner_exec->analysis
* LazyValue->ira
The LazyValue one could be solved by memoizing the results after the
lazy value is resolved, and then it could unref the IrAnalyze.
ZigVars that are determined to be comptime const, could have their
const_value set to that value, instead of using the mem_slot_index
mechanism. This would prevent an IrAnalyze ref in some cases.
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
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.
