Two things the corpus runner got wrong about the engine (#20)

The corpus itself was right the whole way: 1438 cases, 1438 passed, 0
failed, 0 unsupported against the engine at main. What was red was two
things beside it.

The test for a case ahead of the engine used SELECT 1 as a statement the
engine has not reached, and the engine reaches it: SELECT is a statement
head in ISO 39075 and this engine parses one, so the case came back with
a column called 1 and the runner correctly called that a failure rather
than an unsupported. It is CREATE NODE TABLE now, which the engine
refuses with 42001 and the words "CREATE is not implemented yet". A test
like this is a canary by construction and the comment now says so: the
day CREATE lands it has to pick another spelling.

The javadoc on Cell said {@link #equals}, and Cell is a sealed interface
that declares no equals, so the reference did not resolve and the
release profile failed on it. It points at Object#equals(Object), which
is the method the records generate an override of and the one the
sentence is about.

Verified on a Linux box against the engine at 55382df: the corpus module
is BUILD SUCCESS with RunnerTest 12 of 12, and mvn -P release -DskipTests
package is BUILD SUCCESS.

Author: tamnd

zudb-corpus/src/main/java/dev/zudb/corpus/Cell.java

@@ -32,16 +32,17 @@
  * That is a fact about this engine rather than about the corpus, since its
  * own value is one signed 64 bit integer either way.
  *
- * <p>Two of these are the same value when they are {@link #equals}, which
- * is the whole reason for records here. A float is the case that usually
- * needs a comparison written by hand: NaN is not equal to itself and a case
- * asserting NaN has to pass, and 0.0 equals -0.0 and a case asserting -0.0
- * has to fail on 0.0, because the sign of zero is exactly the sort of thing
- * that survives one binding and not another. A record's generated equality
- * compares a double with {@code Double.compare}, which says yes to the
- * first pair and no to the second, so it is already the comparison the
- * corpus wants. {@link Bytes} is the one that is not, since an array
- * compares by identity, and it is written out below.
+ * <p>Two of these are the same value when they are {@link Object#equals(Object)
+ * equal}, which is the whole reason for records here. A float is the case
+ * that usually needs a comparison written by hand: NaN is not equal to
+ * itself and a case asserting NaN has to pass, and 0.0 equals -0.0 and a
+ * case asserting -0.0 has to fail on 0.0, because the sign of zero is
+ * exactly the sort of thing that survives one binding and not another. A
+ * record's generated equality compares a double with
+ * {@code Double.compare}, which says yes to the first pair and no to the
+ * second, so it is already the comparison the corpus wants. {@link Bytes}
+ * is the one that is not, since an array compares by identity, and it is
+ * written out below.
  */
 public sealed interface Cell {
 

zudb-corpus/src/test/java/dev/zudb/corpus/RunnerTest.java

@@ -225,13 +225,18 @@ record Wrong(String what, String body, String want) {}
    * A case the engine has not caught up to is unsupported and not a
    * failure, which is what lets the corpus be the contract and the engine
    * catch up to it. The two classes that say so are 42 and 0A.
+   *
+   * <p>The statement has to be one the engine really has not reached, and
+   * a test like this is a canary by construction: the day CREATE lands,
+   * this stops testing what it says it tests and has to pick another
+   * spelling. It was SELECT before, which the engine now parses.
    */
   @Test
   void aCaseAheadOfTheEngineIsUnsupportedAndNotAFailure() {
     Runner.Ran got = only("""
           - name: one
             doc: d
-            query: SELECT 1
+            query: CREATE NODE TABLE person(uid INT64)
             columns:
               - n
             rows: