add @memmove builtin

[dweiller]

This PR adds a new builtin @memmove(dest: T, src: T) void. It is similar to @memcpy except it can be used for overlapping memory regions. The intended semantics are:

• src and dest can each be a slice, pointer to array, or many-item pointer
• at least one of src and dest must provide a length, and if they both do the lengths must be the same
• unlike (the intended runtime, and current comptime) behaviour of@memcpy, @memmove requires the element type of src and dest to be coercible to each other in memory
• the result of @memmove(dest, src) is that dest[0..len] contains bytes as if a element-by-element loop copied src[0..len] to an auxiliary buffer, and then a second loop copied from that buffer to dest[0..len].

This builtin is currently using up the last ZIR tag.

Related: #767

[nektro]

• should it be @memmove(dest, src) to match order of @memcpy ?
• does @memmove perform the same length equality assertion as @memcpy ?

[dweiller]

• should it be @memmove(dest, src) to match order of @memcpy ?

  • does @memmove perform the same length equality assertion as @memcpy ?

Whoops the order is the same, I just wrote it wrong. It has the same length checks too - will update the OP.

[alexrp]

unlike (the intended runtime, and current comptime) behaviour of@memcpy, @memmove requires the element type of src and dest to be coercible to each other in memory

Just noting that we concluded in the discussion that @memcpy will be changed to only allow in-memory coercions, i.e. coerceInMemoryAllowed. So the builtins will be consistent on this point.

[alexrp]

Additionally, per the @memcpy discussion, the addition of @memmove should include deprecation of std.mem.copy(Backwards,Forwards) (and later removal in 0.15.0).

[dweiller]

Additionally, per the @memcpy discussion, the addition of @memmove should include deprecation of std.mem.copy(Backwards,Forwards) (and later removal in 0.15.0).

Does deprecation mean replace with @compileError, or say so in a doc comment? I see both being done in lib/std.

[alexrp]

Does deprecation mean replace with @compileError, or say so in a doc comment? I see both being done in lib/std.

Doc comment.

I think it's removal that either means outright deletion, or @compileError for an additional release cycle. Not sure if we have any guidelines for when to do which. cc @andrewrk

[dweiller]

I don't know what the aarch64-macos-debug CI issue is - it failed before and after a rebase for @disableIntrinsics(), but I can't really believe this PR is causing the problem.

[dweiller]

Looks like the aarch64-macos-debug CI issue is unrelated, there are other PRs that are having the same failure.

[andrewrk]

macho linker bug filed at #23010