It's still best practice to put `@setEvalBranchQuota` at the top of
the comptime stack, but as Jimmi notes in #1949, when a function
can be called at comptime and also can be the top of the comptime stack,
this compile error is fundamentally unsound.
So now it's gone.
closes#1949
This is not intended to be the long-term implementation as it doesn't
provide various properties that we eventually will want (e.g.
round-tripping, denormal support). It also uses f64 internally so the
wider f128 will be inaccurate.
This deletes some legacy cruft, and produces leaner object files.
Example:
```
var x: i32 = 1234;
export fn entry() i32 {
return x;
}
```
This produces:
```
@x = internal unnamed_addr global i32 1234, align 4
@0 = internal unnamed_addr constant i32* @x, align 8
```
and @0 is never even used. After this commit, @0 is not produced.
This fixes a bug: Zig was creating invalid LLVM IR when one of these
globals that shouldn't exist takes the address of a thread local
variable. In LLVM 8.0.0rc2, it would produce a linker error. But
probably after my bug report is solved it will be caught by the IR
verifier.
https://bugs.llvm.org/show_bug.cgi?id=40652
This deletes some legacy cruft, and produces leaner object files.
Example:
```
var x: i32 = 1234;
export fn entry() i32 {
return x;
}
```
This produces:
```
@x = internal unnamed_addr global i32 1234, align 4
@0 = internal unnamed_addr constant i32* @x, align 8
```
and @0 is never even used. After this commit, @0 is not produced.
This fixes a bug: Zig was creating invalid LLVM IR when one of these
globals that shouldn't exist takes the address of a thread local
variable. In LLVM 8.0.0rc2, it would produce a linker error. But
probably after my bug report is solved it will be caught by the IR
verifier.
https://bugs.llvm.org/show_bug.cgi?id=40652
There's an unfortunate footgun in the current design of error sets.
The debug info type for every error set is the same as the debug info
type of the global error set, which is essentially an enum forward
declaration. The problem is that when we "replace" the forward
declaration with the final value, once we know all the possible errors,
we have to update the pointers of every error set.
So the footgun is that if you ever copy the debug info type of the
global error set, you have to add the address of the pointer to a list
of pointers that need to be updated once we "replace" the forward
declaration. I activated the footgun when I introduced the optimization
that `?anyerror` types are the same size as `anyerror` types (using 0 as
the null value), because I introduced a pointer copy of the global error
set debug info type, but forgot to add it to the list.
I'm sure that there is a better way to code this, which does not have
the footgun, but this commit contains only a fix, not a reworking of the
logic.
closes#1937