Start adding frontend support for relocations

[ehaas]

Add support for initializing pointers with, and doing static asserts with, offsets from global variables.

I'm very open to bikeshedding on names of things / code organization. I moved StringInterner to backend so that Interner could hold StringId values.

Open areas for enhancement:

• Should also support static variables and not just globals.
• Model relocation values with name + bigint instead of name + i64. Right now if the offset overflows we correctly warn but the printed diagnostic is incorrect since the value wraps around.

[Vexu]

I don't love moving StringInterner to the backend since it isn't needed as much there. I'd prefer it to be something more abstract like:

pub const Ptr = struct {
    decl: DeclHandleTypeOfSomeSort,
    offset: Ref,
};

but I don't want to hold you back on my unfinished code maybe something like using @intFromEnum(decl_name_id) would work for now?

Looks good otherwise!

[Vexu]

This looks dangerous. Is it expected that other places won't reach this or is handling it just out of scope for this PR? Shouldn't be a blocker but a comment reminder wouldn't hurt.

[ehaas]

I don't think other paths could reach that, but I changed it to use a separate function for comparing pointers. In doing so I discovered a silly oversight with subtraction where I'd switched the operand order :)

[ehaas]

Did MacOS CI always run on arm64 or did it used to be x86_64? The CI failure also happens on master so I'm trying to figure out if it was always lurking in aro or if something in zig changed that is causing it.

[ehaas]

This patch fixes it, I think:

diff --git a/src/aro/Parser.zig b/src/aro/Parser.zig
index 21df662..69540ac 100644
--- a/src/aro/Parser.zig
+++ b/src/aro/Parser.zig
@@ -5803,13 +5803,10 @@ pub const Result = struct {
                 if (try a.floatConversion(b, a_spec, b_spec, p, float_types[0])) return;
             }
             if (try a.floatConversion(b, a_spec, b_spec, p, float_types[1])) return;
-            if (p.comp.target.cTypeBitSize(.longdouble) == 80) {
+            if (p.comp.target.cTypeBitSize(.longdouble) == 80 or p.comp.target.cTypeBitSize(.longdouble) == 64) {
                 if (try a.floatConversion(b, a_spec, b_spec, p, float_types[0])) return;
             }
             if (try a.floatConversion(b, a_spec, b_spec, p, float_types[2])) return;
-            if (p.comp.target.cTypeBitSize(.longdouble) == 64) {
-                if (try a.floatConversion(b, a_spec, b_spec, p, float_types[0])) return;
-            }
             if (try a.floatConversion(b, a_spec, b_spec, p, float_types[3])) return;
             if (try a.floatConversion(b, a_spec, b_spec, p, float_types[4])) return;
             if (try a.floatConversion(b, a_spec, b_spec, p, float_types[5])) return;

[Vexu]

Did MacOS CI always run on arm64 or did it used to be x86_64? The CI failure also happens on master so I'm trying to figure out if it was always lurking in aro or if something in zig changed that is causing it.

The x86-64 MacOS runner has been deprecated and it was probably switched when I updated to actions/checkout v3 in 59e6078