If an adapted string key with embedded nulls was put in a hash map with
`std.hash_map.StringIndexAdapter`, then an incorrect hash would be
entered for that entry such that it is possible that when looking for
the exact key that matches the prefix of the original key up to the
first null would sometimes match this entry due to hash collisions and
sometimes not if performed later after a grow + rehash, causing the same
key to exist with two different indices breaking every string equality
comparison ever, for example claiming that a container type doesn't
contain a field because the field name string in the struct and the
string representing the identifier to lookup might be equal strings but
have different string indices. This could maybe be fixed by changing
`std.hash_map.StringIndexAdapter.hash` to only hash up to the first
null, therefore ensuring that the entry's hash is correct and that all
future lookups will be consistent, but I don't trust anything so instead
I assert that there are no embedded nulls.
This introduces the new test step `test-c-import`, and removes the
ability of the behavior tests to `@cImport` paths relative to `test`.
This allows the behavior tests to be run without translate c.
As pointed out in the issue this behavior test branches on an undefined
value. That's not valid Zig code.
Also behavior tests should not depend on the standard library in this
manner. They need to minimally isolate the specific language thing that
is being tested.
Closes#12681
During semantic analysis the value may be an unresolved lazy value
which makes using `toUnsignedInt` invalid.
Add assertions to detect similar issues in the future.
Closes#18624
The original test was checking the types of irrelevant slices, the test
is for slicing of multi-pointers _without_ an end value, but the types
of slices with an end value were being checked.
