To an average user, it may be unclear why these notes are not just in
the reference trace; that's because they are more important, because
they are inline calls through which comptime values may propagate. There
are now 3 possible wordings for this note:
* "called at comptime here"
* "called inline here"
* "generic function instantiated here"
An alternative could be these wordings:
* "while analyzing comptime call here"
* "while analyzing inline call here"
* "while analyzing generic instantiation here"
I'm not sure which is better -- but this commit is certainly better than
status quo.
Inline calls which happened in the erroring `AnalUnit` still show as
error notes, because they tend to make very important context (e.g. to
see how comptime values propagate through them). However, "earlier"
inline calls are still useful to see to understand how something is
being referenced, so we should include them in the reference trace.
When `-freference-trace` is not passed, we want to show exactly one
reference trace. Previously, we set the reference trace root in `Sema`
iff there were no other failed analyses. However, this results in an
arbitrary error being the one with the reference trace after error
sorting. It is also incompatible with incremental compilation, where
some errors might be unreferenced. Instead, set the field on all
analysis errors, and decide in `Compilation.getAllErrorsAlloc` which
reference trace[s] to actually show.
Error messages never contain periods or grave accents.
Get rid of the periods and use apostrophes instead in
probably the only two error messages that had them.
* ucontext_t ptr is 8-byte aligned instead of 16-byte aligned which @alignCast() expects
* Retrieve pc address from ucontext_t since unwind_state is null
* Work around __mcontext_data being written incorrectly by the kernel
These symbols are defined in the statically-linked startup code. The real
libc.so.7 contains strong references to them, so they need to be put into the
dynamic symbol table.
Textual PTX is just assembly language like any other. And if we do ever add
support for emitting PTX object files after reverse engineering the bytecode
format, we'd be emitting ELF files like the CUDA toolchain. So there's really no
need for a special ObjectFormat tag here, nor linker code that treats it as a
distinct format.
* NT_FREEBSD_ABI_TAG was manually adjusted from using a hardcoded value to using
__FreeBSD_version which will be defined by the compiler.
* GCJ stuff was removed.
* HAVE_CTORS definitions were removed.
