From 09a57583a4ccce30603ffc8d0e3d7359dc3cb978 Mon Sep 17 00:00:00 2001 From: mlugg Date: Mon, 18 Sep 2023 14:49:18 +0100 Subject: compiler: preserve result type information through address-of operator This commit introduces the new `ref_coerced_ty` result type into AstGen. This represents a expression which we want to treat as an lvalue, and the pointer will be coerced to a given type. This change gives known result types to many expressions, in particular struct and array initializations. This allows certain casts to work which previously required explicitly specifying types via `@as`. It also eliminates our dependence on anonymous struct types for expressions of the form `&.{ ... }` - this paves the way for #16865, and also results in less Sema magic happening for such initializations, also leading to potentially better runtime code. As part of these changes, this commit also implements #17194 by disallowing RLS on explicitly-typed struct and array initializations. Apologies for linking these changes - it seemed rather pointless to try and separate them, since they both make big changes to struct and array initializations in AstGen. The rationale for this change can be found in the proposal - in essence, performing RLS whilst maintaining the semantics of the intermediary type is a very difficult problem to solve. This allowed the problematic `coerce_result_ptr` ZIR instruction to be completely eliminated, which in turn also simplified the logic for inferred allocations in Sema - thanks to this, we almost break even on line count! In doing this, the ZIR instructions surrounding these initializations have been restructured - some have been added and removed, and others renamed for clarity (and their semantics changed slightly). In order to optimize ZIR tag count, the `struct_init_anon_ref` and `array_init_anon_ref` instructions have been removed in favour of using `ref` on a standard anonymous value initialization, since these instructions are now virtually never used. Lastly, it's worth noting that this commit introduces a slightly strange source of generic poison types: in the expression `@as(*anyopaque, &x)`, the sub-expression `x` has a generic poison result type, despite no generic code being involved. This turns out to be a logical choice, because we don't know the result type for `x`, and the generic poison type represents precisely this case, providing the semantics we need. Resolves: #16512 Resolves: #17194 --- test/behavior/pointers.zig | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'test/behavior/pointers.zig') diff --git a/test/behavior/pointers.zig b/test/behavior/pointers.zig index 3122ae23d5..1cc46fcd1a 100644 --- a/test/behavior/pointers.zig +++ b/test/behavior/pointers.zig @@ -548,3 +548,21 @@ test "pointer to array has explicit alignment" { const casted = S.func(&bases); try expect(casted[0].a == 2); } + +test "result type preserved through multiple references" { + const S = struct { x: u32 }; + var my_u64: u64 = 12345; + const foo: *const *const *const S = &&&.{ + .x = @intCast(my_u64), + }; + try expect(foo.*.*.*.x == 12345); +} + +test "result type found through optional pointer" { + const ptr1: ?*const u32 = &@intCast(123); + const ptr2: ?[]const u8 = &.{ @intCast(123), @truncate(0xABCD) }; + try expect(ptr1.?.* == 123); + try expect(ptr2.?.len == 2); + try expect(ptr2.?[0] == 123); + try expect(ptr2.?[1] == 0xCD); +} -- cgit v1.2.3