build failures for lib/std/Build/Fuzz/WebServer.zig on armv7l

[M-Evans]

Zig Version

0.14.0-dev.2802+257054a14

Steps to Reproduce and Observed Behavior

attempt zig build in any project on an armv7l machine

$ uname -a
Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

Expected Behavior

expected: zig build to build the project.

actual:

$ zig build
/opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Build/Fuzz/WebServer.zig:633:9: error: expected type 'usize', found 'u64'
        file_size,
        ^~~~~~~~~
/opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Build/Fuzz/WebServer.zig:633:9: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
/opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/posix.zig:4732:13: note: parameter type declared here
    length: usize,
            ^~~~~
referenced by:
    coverageRun: /opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Build/Fuzz/WebServer.zig:562:50
    callFn__anon_63280: /opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Thread.zig:486:13
    10 reference(s) hidden; use '-freference-trace=12' to see all references

I then added an @intCast here:

zig/lib/std/Build/Fuzz/WebServer.zig

Line 633 in f38d7a9

file_size,

which makes the error go away. yet my build still fails with a separate issue:

$ zig build
/opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Build/Fuzz/WebServer.zig:654:5: error: TODO: lower @memcpy to a for loop because the element types have different ABI sizes
    @memcpy(sorted_pcs.items(.pc), pcs);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
    coverageRun: /opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Build/Fuzz/WebServer.zig:562:50
    callFn__anon_63280: /opt/zig/zig-linux-armv7a-0.14.0-dev.2802+257054a14/lib/std/Thread.zig:486:13
    10 reference(s) hidden; use '-freference-trace=12' to see all references

[alexrp]

I'll take a look at the file_size issue.

@mlugg @Rexicon226 perhaps one of you would be interested in tackling the Sema @memcpy issue?