add error.EndOfStream to readEnum() and isBytes() so that users can
catch these errors. this also prevents them from panicing with
'invalid error value' on EndOfStream.
test both methods.
This adds scheme guessing when loading proxies, such that
`HTTP_PROXY=127.0.0.1` and such are valid now and it behaves identically
to `HTTP_PROXY=http://127.0.0.1`. Additionally fixed a typo that was
causing loadDefaultProxies to never populate the https_proxy.
The main problem being fixed here is there was a getOrPut() that held on
to a reference to the value pointer too long, and meanwhile the call to
`lowerConst` ended up being recursive and mutating the hash map,
invoking undefined behavior.
caught via #17719
* 128-bit integer multiplication with overflow
* more instruction encodings used by std inline asm
* implement the `try_ptr` air instruction
* follow correct stack frame abi
* enable full panic handler
* enable stack traces
While this is a less flexible approach to being able to
allocated the PHDR anywhere in file, it is sadly generally expected
by the tooling in the wild.
This logic is not correct in most cases. If any instruction needs to
operate with different semantics within `@TypeOf`, it should be made to
do so explicitly.
This broke a line in `std.mem`: I have opted to fix this in std for now,
since as far as I know it's not yet been discussed which operations (if
any) should be special-cased like this within `@TypeOf`.
Having simplified these functions in a previous commit, I felt inclined
to refactor their names, which were previously quite inconsistent. There
are now 4 "core" functions:
* `resolveValue` (previously `resolveMaybeUndefVal`) allows runtime-known and undef values.
* `resolveConstValue` (previously `resolveConstMaybeUndefVal`) allows undef but not runtime-known values.
* `resolveDefinedValue` (name unchanged) allows runtime-known values but not comptime-known undef.
* `resolveConstDefinedValue` (previously `resolveConstValue`) does not allow runtime-known or undef values.
You can see the inconsistencies in the old names here - sometimes we
specified "maybe undef", and sometimes we went the other way by
specifying "defined". With the new names, the most common function,
`resolveValue`, has the shortest name and does the most general thing,
and is the baseline that the other functions are adding logic to.
Some other functions were also renamed:
* `resolveMaybeUndefLazyVal` -> `resolveValueResolveLazy`
* `resolveMaybeUndefValIntable` -> `resolveValueIntable`
* `resolveMaybeUndefValAllowVariables` -> `resolveValueAllowVariables`
