Partial revert of 1e963053d0ff67361b587b046a917375e963d5e9. Now that
lldb has a new method for accessing this data that does not require
manual updating, there is no longer any reason to share this data.
And make it not do any installation, only objcopying. We already have
install steps for doing installation.
This commit also makes ObjCopyStep properly integrate with caching.
Many `Type`s can correspond to the same `CType`, so this reduces the
number of used locals by 27760 when compiling only-c.
Also, disabled some tests that were only passing by accident and
shouldn't really be considered working.
I believe the reason we had that check in the first place was because for both `pthread_setname_np` and `pthread_getname_np` man says:
```
CONFORMING TO
These functions are nonstandard GNU extensions; hence the suffix "_np" (nonportable) in the names.
```
However, this `is_gnu` check was never consistently applied; it was
missing in `setName` in the Linux case. It is also missing on all other call sites for other platforms (macOS, iOS, et al.).
Though, that could be because it may only apply to Linux.
I think for a best-effort approach it is okay to drop this. It's probably less non-standard than man makes it out to be.
I noticed a comment saying that the intent of a code's author was unclear.
What happened is that the author forgot to put the check for whether the
thread is the calling thread (`self.getHandle() ==
std.c.pthread_self()`) in the `if (use_pthreads)`.
If the thread is the calling thread, we use `prctl` to set or get the
thread's name and it does not take a thread id because it knows the id
of the thread we're calling `getName` or `setName` from.
I have found a source saying that using `pthread_setname_np` on either the calling thread
or any other thread by thread id would work too (so we don't need to
call `prctl`) but I was not sure if that is the case on all systems
so we keep using `pthread_setname_np` if we have a
specific thread that is not the thread we're calling from, and `prctl`
otherwise.
- Combine mulXi3 routines for follow-up cleanup.
- DRY up Dwords and Twords
- rename both to HalveInt and use instance
* Justification: Not all processors have word size 32 bit.
* remove test file from CMakeLists
* DRY things.
After this, the last MSVC warnings are in behavior/bugs/529.zig:
behavior.c(37971): warning C4133: 'function': incompatible types - from 'A__8479 *' to 'A__8474 *'
behavior.c(37974): warning C4133: 'function': incompatible types - from 'A__8480 *' to 'A__8474 *'
* Support always_tail and never_tail/never_inline with a comptime callee using clang
* Support never_inline using gcc
* Support never_inline using msvc
Unfortunately, can't enable behavior tests because of the conditional support.
And additionally support writing files to source files. This means a
custom build step in zig's own build.zig is no longer needed for copying
zig.h because it is handled by WriteFileStep.
* Implement @fieldParentPtr on a union
* Refactor field access to ensure that it is handled consistently
* Remove `renderTypecast` as it is now behaves the same as `renderType`
Forcing the key to be of the same type as the sorted items used during
the search is a valid use case.
There, however, exists some cases where the key and the items are of
heterogeneous types, like searching for a code point in ordered ranges
of code points:
```zig
const CodePoint = u21;
const CodePointRange = [2]CodePoint;
const valid_ranges = &[_]CodePointRange{
// an ordered array of ranges
};
fn orderCodePointAndRange(
context: void,
code_point: CodePoint,
range: CodePointRange
) std.math.Order {
_ = context;
if (code_point < range[0]) {
return .lt;
}
if (code_point > range[1]) {
return .gt;
}
return .eq;
}
fn isValidCodePoint(code_point: CodePoint) bool {
return std.sort.binarySearch(
CodePointRange,
code_point,
valid_ranges,
void,
orderCodePointAndRange
) != null;
}
```
It is so expected that `std.sort.binarySearch` should therefore support
both homogeneous and heterogeneous keys.
