Infer destination type of cast builtins using result type

[mlugg]

This PR implements #5909. Affected builtins:

• @addrSpaceCast
• @alignCast
• @bitCast
• @errSetCast
• @floatCast
• @intFromFloat
• @intCast
• @enumFromInt
• @floatFromInt
• @ptrFromInt
• @ptrCast
• @truncate

The language changes here are mostly explained in that issue, but there's one slightly subtle thing: pointer casts. It's common to nest different kinds of pointer cast, e.g. @alignCast(a, @ptrCast(T, ptr)). The problem is, if we naively implemented these casts, such usages would become much more convoluted; e.g. @alignCast(@as(*align(1)T, @ptrCast(T))). The solution @andrewrk and I agreed upon is that chained pointer cast builtins are a special case. Any sequence of the following builtins...

• @ptrCast
• @alignCast
• @addrSpaceCast
• @constCast
• @volatileCast

... is special-cased to act as a single operation with a single result type. This allows you to just write e.g. @alignCast(@ptrCast(ptr)); similarly, you can cast every pointer property using @ptrCast(@alignCast(@addrSpaceCast(@constCast(@volatileCast(ptr))))) (please don't though, that's awful). Note that the order of these operations doesn't matter; you can reorder them and will get the same ZIR.

This PR introduces zig fmt fixups for most of the builtins changed. Exceptions include:

• @alignCast cannot be automatically fixed, as the old usage doesn't mention the pointer type.
• @addrSpaceCast cannot be automatically fixed for the same reason.
• @truncate had a slightly odd usage which means its fixup is incorrect for vector operands. This incorrect fix will never cause a silent bug; always a compile error.

[Snektron]

If this is just going to replace @thing with @as(@thing( everywhere then im not sure that it improves anything.

Sorry to be so pessimistic about this change lol

[ghost]

The original idea behind the proposal was sound, but browsing through the actual changeset, this feels like a net negative for readability.

Edit: Looks like @Snektron beat me to it 😄

[mlugg]

These changes are simple auto-formats, which use @as indiscriminately to ensure correctness. In all code I manually migrated, readability was equivalent or improved. Here are a couple of examples:

// old:
const hdr = @ptrCast(
    *const macho.mach_header_64,
    @alignCast(@alignOf(macho.mach_header_64), mapped_mem.ptr),
);
// new:
const hdr: *const macho.mach_header_64 = @ptrCast(@alignCast(mapped_mem.ptr);

// old:
const self = @ptrCast(*Self, @alignCast(@alignOf(Self), ctx));
// new:
const self: *Self = @ptrCast(@alignCast(ctx));

// old:
var test_ptr = @ptrFromInt(*allowzero addrspace(.fs) u64, 0);
// new: (no shorter, but more readable, which is a very common case)
var test_ptr: *allowzero addrspace(.fs) u64 = @ptrFromInt(0);

The vast majority of use cases of @as in the auto-formatted code are redundant; result type inference works pretty well. Any of these builtins in a function parameter, struct or array init, const or var init with a type annotation, etc, will all be able to infer their result type no problem.

[Snektron]

The vast majority of use cases of @as in the auto-formatted code are redundant

Sure. As it stands, though...

[mlugg]

A language change having an ugly auto-format doesn't really matter; the alternative is there being no auto-fixup and the only migration path being a manual rewrite. Someone could easily go through std (etc) and start manually tweaking these calls to use the new syntax more cleanly; ugly code is temporary, a better language is forever. I personally didn't fancy making the 9000 lines of changes manually - you're welcome to work on cleaning them up if it's going to be an issue for you, but I don't really see how it would be. The language change itself, when correctly applied, results in nicer code, almost across the board.

[MasonRemaley]

This PR solves a major problem in the ZON parser I'm working on.

ZON currently cannot support non-exhaustive enums since ZON literals are untyped but non-exhaustive enums cannot be instantiated without passing destination type to @enumToInt in the case where the value has no tag.

If @intToEnum instead infers the destination type as it does in this PR, this becomes a non-issue.

[andrewrk]

Note that for some reason CI checks don't run if there are any merge conflicts.

[andrewrk]

Great work! I'm recompiling zig1.wasm right now and will merge shortly.

[iacore]

I think in some cases, @alignCast can be somewhat fixed by simple removing the first argument.

I'm updating https://github.com/greenfork/jzignet, and most of the usage there can be automatically fixed.