* Correct parsing of DWARF line_info section
* Fix reading of udata/sdata encoded attributes
* Add definition for DW_AT_alignment
Even though it's been standardized in DWARF5 some compilers produce it
anyway for DWARF4 infos too.
* Fix reading of reference attributes
* Distinguish between absolute/relative addresses
This effectively takes one-bit from the length field and uses it as the
sign bit. It reduces the size of an Int from 40 bits to 32 bits on a
64-bit arch.
This also reduces std.Rational from 80 bits to 64 bits.
A constant Int is one which has a value of null for its allocator field.
It cannot be resized or have its limbs written. Any attempt made to
write to it will be caught with a runtime panic.
This removes the compiler_rt.setXmm0 hack. Instead, for
the functions that use i128 or u128 in their parameter and
return types, we use `@Vector(2, u64)` which generates
the LLVM IR `<2 x i64>` type that matches what Clang
generates for `typedef int ti_int __attribute__ ((mode (TI)))`
when targeting Windows x86_64.
The flag is for generating correct arm-thumb interwork veneers in the
assembly code __aeabi_{memcpy,memset,etc} functions.
Armv6m only does thumb code generation regardless of whether arm or
thumb is selected and armv6t2 uses the newer thumb 2 set. All other
versions that zig supports pre-armv7 need the veneers and hence the
flag. Armv5 is actually armv5t.
Relevant code from clang/lib/Basic/Targets/Arm.cpp
```c
bool ARMTargetInfo::isThumb() const {
return ArchISA == llvm::ARM::ISAKind::THUMB;
}
bool ARMTargetInfo::supportsThumb() const {
return CPUAttr.count('T') || ArchVersion >= 6;
}
bool ARMTargetInfo::supportsThumb2() const {
return CPUAttr.equals("6T2") ||
(ArchVersion >= 7 && !CPUAttr.equals("8M_BASE"));
}
```
Also see
http://www.llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARM.td
In addition to the pointer, this gives some visual feedback to the user
that the element is interactive. This is a very common style pattern
across the web.
Now returns a copy of the removed kv instead of a pointer to the removed kv. The removed kv gets overwritten when shifting the hash map after the removal, so returning a pointer to it will have another kv's values in it after the return.
This bug had some nasty downstream effects in things like BufSet and BufMap where delete would free a still in-use KV and leave the actually removed KV un-free'd.
