Making it build and run with zig 0.16.0

[michaelo]

zig-sqlite commit

34df489 for #201 or fb73a6c for current master

Zig version

0.16.0

Steps to reproduce

• Clone repo
• Either:
  • git checkout fb73a6c (master)
  • or checkout zig 16 update #201 (34df489) which solves a lot of the issues

zig build test

Expected behaviour

Successful build and test execution with no errors.

Errors and possible fixes

Basing off of PR #201 which appears to solve a lot of the issues, the following still remains:

Multiple of the following build time errors:

build.zig:160:45: error: missing struct field: items
   var flags: std.ArrayList([]const u8) = .{}

Which can be fixed with:
var flags: std.ArrayList([]const u8) = .empty

Then the following runtime errors:

vtab.zig:769:45: error: '[*c]cimport.struct_sqlite3_vtab' could have null values which are illegal in type '*cimport.struct_sqlite3_vtab'
            const nullable_state: ?*State = @fieldParentPtr("vtab", vtab);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

... which can be solved with:

            const vtab_ptr: *c.sqlite3_vtab = vtab orelse unreachable;
            const state: *State = @fieldParentPtr("vtab", vtab_ptr);

And we have io.TimeStamp which has removed error condition:

sqlite.zig:3733:49: error: expected error union type, found 'Io.Timestamp'
    const timestamp = clock.now(std.testing.io) catch std.Io.Timestamp.zero;

... fixed with removing the catch-part.

And for fuzz test which has changed interface:

sqlite.zig:4103:40: error: expected type 'fn (T, *testing.Smith) anyerror!void', found 'fn (T, []const u8) anyerror!void'
    try testing.fuzz(Context{}, Context.testOne, .{});

... this I'm more uncertain off as I have not yet worked with zig fuzz, but the following at least compiles and needs to be properly tested:
Update testOne-signature:
from:

fn testOne(_: @This(), input: []const u8) anyerror!void {

to:

fn testOne(_: @This(), input: *testing.Smith) anyerror!void {

and correspondingy update test testOne body to use 'input.in.?' instead of 'input'.

I'd be happy to provide a pull request for all this, but would need to know if we can build off of the #201 or not.