This will make stack traces and debugging experience more consistent
in the sense that the presence of source lines in stack traces will
not be dependent on the current working directory of the running process.
There are still a few occurrences of "stage1" in the standard library
and self-hosted compiler source, however, these instances need a bit
more careful inspection to ensure no breakage.
When a local defined outside a loop dies inside the loop, it can still
be needed on subsequent loop iterations, so reuse of the local must be
deferred until after the loop ends. This causes behavior tests to pass.
In both backends they did not observe the Liveness information for try
instructions. Now they do. For the C backend this is necessary for
correctness; for the LLVM backend, it improves code generation.
In general the C backend should lower to human-maintainable C code
whenever possible. Directly using C types that one would use when
writing C code is one part of the strategy.
The concern with including stdint.h is C89 compatibility. Well, we can
just check the C std lib version before deciding to include that header.
`@llvm.dbg.value` is absolutely useless, adding a temporary alloca
to store the constant in will make it actually show up in debuggers.
The effect on performance should be minimal since there is only one
store and it the change is not applied to ReleaseSafe builds.
```zig
fn foo(a: u32, b: []const u8, c: bool, d: enum { yes, no }) void {
_ = a; _ = b; _ = c; _ = d;
}
```
before:
```
Breakpoint 1, a.foo (a=<optimized out>, b=..., c=<optimized out>, d=<optimized out>) at a.zig:18
18 _ = d;
```
after:
```
Breakpoint 1, a.foo (a=1, b=..., c=false, d=yes) at a.zig:15
15 _ = a; _ = b; _ = c; _ = d;
(gdb) p b
$1 = {ptr = 0x20854f <a.main.anon_3888> "bar", len = 3}
```
Different (simple) tuple types do not necessarily print out as different strings.
This is issue would be caused by passing std.fmt.Formatter to std.fmt.format.
