test "ondemand struct iteration types" is failing

[travisstaloch]

@sharpobject i started working on integrating your changes and removing libc dependency here using zig 0.10.0

i had to sligntly alter the asm version of mm256_shuffle_epi8 you posted in discord to get some of the tests passing.

so this

 var ret: u8x32 = asm (
    \\ vpshufb %[a], %[b], %[ret]
    : [ret] "=x" (-> u8x32)
    : [a] "x" (a),
      [b] "x" (b)
);

became the following - taken from my benchmarks game solution

return asm (
    \\ vpshufb %[mask], %[x], %[out]
    : [out] "=x" (-> v.u8x32),
    : [x] "+x" (x),
      [mask] "x" (mask),
);

anyway the problem now is that the test "ondemand struct iteration types" is failing. you can see it here. i think it has something to do with the _prev1/2/3() methods.

its wierd, if you look here, i tried comparing results with the old versions from utils.c. but as soon as i link libc, the error goes away and the test passes.

let me know if you spot anything amiss with the _prevN() methods or have any ideas about what is happening. this is the only failing test left out of 24 and i'm not sure whats causing it.

[travisstaloch]

so strange that all the tests pass if you uncomment this line https://github.com/travisstaloch/simdjzon/blob/ac0a71bebc44d538ef1068284ba6bbe7860b5181/build.zig#L6

[travisstaloch]

here's a stack trace of the failure with some added debugging. i added this line to ondemand.Parser.peek

cmn.println("parser {*} position {*} len_hint {}", .{parser, position, len_hint});

not sure why the pointers change so much here at the second line.

parser ondemand.Parser@7ffdacf40540 position u32@7f44fe21800c len_hint 10
parser ondemand.Parser@74203a227422202c position u32@33322e31203a2266 len_hint 1

[travisstaloch]

fixed by going back to linking libc. not sure whats causing this seems like maybe a c abi issue?

other possible causes:

• excessive use of inline fn
• the ondemand parser relies on stage1 being lenient w/ regard to *T vs *const T. this is one of the issues that needs to be addressed in order to build w/ the stage2 compiler.

will revisit once stage2 rewrite is complete. perhaps some of those changes can be ported to this branch.