for tests why not use library-based expect instead of comment-based CHECK hack?

[timotheecour]

#62 (comment)

This was for convenience when basics.d was turned into a lit test.

what's a lit test? is that things like // CHECK: xyz = 3, 9.81 in tests/calypso/constexpr_ctor.d ?

on that note, why use comment-based CHECK instead of something more straightforward such as library call expect?

tests/calypso/constexpr_ctor.d:

// ...
 import std.stdio : writeln;
 void main()
 {
     // CHECK: xyz = 3, 9.81
     writeln("xyz = ", xyz.n, ", ", xyz.f);
 }

instead how about:

import calypso.util : expect;
 void main()
 {
  expect(xyz.n == 3 . && xyz.f == 9.81);
}

eg implementation of expect

module calypso.util;
pragma(inline, true)
void expect(string file=__FILE__, int line=__LINE__, string fun=__FUNCTION__, T)(auto ref T a){
    if(a) return;
     writeln(file, ":", line," ", fun, " expect FAIL");
     // increment counter of expect failures
     // can add more logic here if needed, eg assert on 1st expect failure if needed, etc
}

ldc uses CHECK in places where expect would be hard to use, eg to check the IR eg

// https://github.com/ldc-developers/ldc/blob/3b63effd3fa3200d4137260ce68541a55dcde21c/tests/debuginfo/gline_tables_only2.d#L10

int main() {
  // CHECK: ret i32 0, !dbg
  return 0;
}

however in the test cases of calypso, what's advantage over more straightforward (and easier to read/write) library call such as expect?

[Syniurge]

lit looks for RUN directives : https://llvm.org/docs/CommandGuide/lit.html
while CHECK are for FileCheck: https://llvm.org/docs/CommandGuide/FileCheck.html

But you're right, CHECK directives are better suited for cases where we can't use a solution like assert or your expect, e.g: checking the IR, compiler errors/warnings, etc.
assert/expect would make debugging possible without adding breakpoints, and also benefits from D syntax and code highlighting.

I'll stop using CHECK and replace every CHECK by expect at some point. (to make the IR easier to read, it'd be better not to inline expect though)

[timotheecour]

to make the IR easier to read, it'd be better not to inline expect though

if keeping IR clean is a concern, maybe also optionally making expect nothrow to avoid adding exception handling boilerplate, eg:

version(calypso_expect_simple){
nothrow
pragma(inline, true) // needed to apply the body (which does nothing) inline and avoid affecting the IR
void expect(string file=__FILE__, int line=__LINE__, string fun=__FUNCTION__, T)(auto ref T a){
// do nothing
}
} else {
pragma(inline, true)
void expect(string file=__FILE__, int line=__LINE__, string fun=__FUNCTION__, T)(auto ref T a){
}
}