Why does `dune build @runtest` accept `let () = 1`?

Learning
1

Hi,

Am I running dune incorrectly somehow so that it finds nothing to do
even when I have an obvious type error in my code?

Here’s my dune call and its output:

accessor/test [master●] » dune build -w --auto-promote @runtest
Entering directory '/home/damonwang/prj/accessor'
                                          ^C
********** NEW BUILD **********

Done: 0/0 (jobs: 0)%

Here’s the code I expect to cause a type error:

accessor/test [master●] » git diff accessor_tests.ml 
 diff --git a/test/accessor_tests.ml b/test/accessor_tests.ml
 index c9c244a..2722e9f 100644
 --- a/test/accessor_tests.ml
 +++ b/test/accessor_tests.ml
 @@ -41,3 +41,7 @@ let%expect_test "match_" =
    print_s [%sexp (Accessor.match_ Foo.a b : (int, Nothing.t Foo.t) Either.t)];
    [%expect {| (Second B) |}]
  ;;
 +
 +type 'a t = (string list * (string list * 'a) list) [@@deriving accessors]
 +
 +let () = 1

Surprisingly, dune rules reports (other) build errors:

accessor/test [master●] » dune rules
Entering directory '/home/damonwang/prj/accessor'
File "test/accessor_tests.ml", line 34, characters 16-34:
34 |     [@@deriving accessors, sexp_of]
                     ^^^^^^^^^^^^^^^^^^
Error: Ppxlib.Deriving: 'accessors' is not a supported type deriving generator
Done: 316/319 (jobs: 1)%

This is not the behavior I expected given dune dump --help:

Dump Dune internal rules for the given targets. If no targets are
given, dump all the internal rules.

I’m on dune 2.7.1 and this was at the tip of the accessor repo:

accessor/test [master●] » LESS= git log -r .
commit ee4f078637ac81e962a955db643d4af895760a07
Author: Xavier Clerc <xclerc@janestreet.com>
Date:   Mon Feb 17 13:14:55 2020 +0000

v0.14-preview.122.08+346
accessor/test [master●] » git remote get-url origin
https://github.com/janestreet/accessor.git
2

Firstly, I suggest you first compile your code with a plain dune build @runtest and see what happens. dune rules may not work if the code cannot be compiled. By the way, dune rules is not really intended to be used by the casual user.

Secondly, if there is an error before the code you added, the compiler may report that and halt, and not reach the code you added at all.

Cheers,
Nicolas

3

I should have been more clear that the bit about dune rules is an aside. My real question is,

When I dune build @runtest with an obvious type error in my code, why doesn’t it give me any type errors?

The output of dune build @runtest is

accessor/test [master●] » dune build -w --auto-promote @runtest
Entering directory '/home/damonwang/prj/accessor'
                                          ^C
********** NEW BUILD **********

Done: 0/0 (jobs: 0)%

I would have expected to see something about the

let () = 1
4

The Jane Street package dune files don’t currently include a (inline_tests) clause, which means dune doesn’t think there are any tests in that directory. As a result, it makes no attempt to compile those modules, and so you don’t get an error.

If you edit the dune file:

(library (name accessor_tests) (libraries accessor core_kernel)
 (inline_tests)
 (preprocess (pps ppx_jane ppx_accessor)))

I would then expect the compile error to manifest.

5

Thanks, that fixed it!

Why does accessor ship with the tests disabled? (/ Would you take a PR to fix that?)

6

Once we have switched to using Dune inside Jane Street, we’ll look into allowing tests to build outside our walls. In the meantime, accepting such patches for individual packages would be too much too maintain.