New VFS

[cole-miller]

Very WIP.

[codecov]

Codecov Report

Attention: Patch coverage is 79.16667% with 190 lines in your changes are missing coverage. Please review.

❗ No coverage uploaded for pull request base (dqlite-next@9578db5). Click here to learn what that means.

Files	Patch %	Lines
src/vfs2.c	74.96%	98 Missing and 86 partials ⚠️
src/lib/sm.c	28.57%	4 Missing and 1 partial ⚠️
test/unit/test_vfs2.c	99.40%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff               @@
##             dqlite-next     #552   +/-   ##
==============================================
  Coverage               ?   81.15%           
==============================================
  Files                  ?      194           
  Lines                  ?    28045           
  Branches               ?     5211           
==============================================
  Hits                   ?    22761           
  Misses                 ?     3586           
  Partials               ?     1698           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[just-now]

This is the first pass. Will continue reading the logic.

[just-now]

Looks like wal_prev_fixed_name and wal_cur_fixed_name could be const.

[cole-miller]

They are "owned" and need to be freed at the end of the file object's lifetime, unlike moving_name which is "borrowed" from SQLite (but guaranteed to be valid until xClose, see https://sqlite.org/c3ref/vfs.html. That's why I've left the distinction here

[just-now]

Looks to be a common part for this and next else if { statement. Consider moving this common part up to the QUEUE__FOREACH() {

[cole-miller]

The calls are a bit different, it's

strncmp(cur->wal->wal.moving_name, f->db_shm.name, ...)

vs

strncmp(f->wal.moving_name, cur->db->db_shm.name, ...)

I can't see how to factor out what's common without making the code more complicated

[cole-miller]

I'm going to merge this into dqlite-next and we can iterate on it there!