5775f188

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Give the facts somewhere to live

A rule that cannot answer from one module needs the facts of more than one, and
they have to be written down somewhere between the reading and the asking. This
is that somewhere: one SQLite database, one table per fact, owned by the rule
that writes it.

What a rule above the module level does with facts is join them, so the store is
a database rather than a pile of files. The envelope tables are the ones every
run writes whatever its rules are: which packages there were, which modules each
was held to covering, what each module turned out to be, and which suppressions
were written in it.

A fact is a row rather than a keyed entry. Two instances in one module are two
facts, and there is nothing to key them on that is not invented.

Where the store lives is a two-constructor type rather than a path, because
`:memory:` is not a file name: it is SQLite's word for having no file at all.

Merging says which tables it has nowhere to put rather than dying on the first
row. A store written by an executable with a rule this one lacks is a real
thing, and SQLite's answer to it is `no such table`, which is a sentence about a
name nobody chose from a run that has not written its report yet.

The stamp is keyed on the format version, so a store merged from one written in
another format shows up as a second row and the run can say so. A tool version
beside it would not work: keyed on the format, a second store's row at this same
format is dropped by the insert, and two versions where one is never read is a
check that reads as stronger than it is.

No rule uses any of this yet. The next commit adds the level a rule declares and
the first rule that needs one, and it is separate because this is a thing that
can be tested on its own and that is a thing that can be read on its own.

Timeline