Also: can you add your test(s) to the testsuite?

Happy to write a test, however I'm not too sure how to proceed.

Happy to write a test, however I'm not too sure how to proceed.

Can't you produce a simplified version of what's happening on ocaml/dune#1792 ?

it seems easy to write as a shell cram test. How can I write such a test with the current test infrastructure?

You can launch a shell script from an ocamltest script:

foo.ml:

(* TEST
  script = "${test_source_directory}/foo.sh"
  * setup-ocamlc.byte-build-env
  ** script
 *)
Printf.printf "hello\n"

foo.sh:

#!/bin/sh
ocamlc foo.ml && ./a.out

@damiendoligez thanks. However, the ocamlc I have access to inside the script is not the right one. It is the one accessible from the PATH of my shell rather than the newly built one.

For instance, if I do ocamlc -version inside the script, I get 4.07.1.

You don't really need to run a script though.
You could just have all your .ml files in your test directory, and call the compiler via ocamltest as is done for various other tests.

How do I do that?

FTR, this is my test:

#!/bin/sh

set -e

cat > a.ml <<EOF
let x = 42
EOF

cat > lib__.ml <<EOF
module A = Lib__A
EOF

cat > lib.ml <<EOF
module A = A
EOF

cat > user_of_lib.ml <<EOF
open Lib
let x = A.x
EOF

ocamlc -no-alias-deps -w -49 -c lib__.ml
ocamlc -no-alias-deps -w -49 -open Lib__ -o lib__A.cmo -c a.ml
ocamlc -no-alias-deps -w -49 -open Lib__ -o lib.cmo -c lib.ml
ocamlc -no-alias-deps -w -49 -c user_of_lib.ml

You do some variation of this.

Sorry, I have very superficial knowledge of ocamltest and I don't really understand what test_locations.ml is doing or how to encode my test in ocamltest comments.

I did the following manual testing: I tried to build dune with both trunk and this PR. It fails with trunk but passes with this PR. Do you mind if I don't add a test in the testsuite at this point? I'm happy to add a test in the future once I understand ocamltest better.

I'd be happy to get this PR merged without a test for the moment.

Do you mind if I don't add a test in the testsuite at this point?

I do actually.
I agree it would be nice if ocamltest was documented, but given that there are already multiple examples in the test suite, and that I pointed you to one, I have no doubt that can hack something that works :)

Btw, your test is nice for the issue you're intending to fix, but I think you should also add the test of MPR#6886, since it looks like the initial version of this GPR was reintroducing that bug.

The result would look less readable that the script anyway, so I'd rather make the script version work.

I’ll try to see if the test can be done more neatly, but I agree with @trefis that their presence is important (the tests I added to #2041 were painful to write too...).

Ultra-minor nit, but this GPR should be added to 2041 in Changes, rather than suppressing the CI test.

Thanks @dra27! I updated the changelog. I definitely agree that such tests are important, though given that this is time sensitive, we might have to merge the fix without a test initially to not delay 4.08.

I’ll try to see if the test can be done more neatly

Thanks @dra27, but it's OK, I added the test.
I also removed the non-working test which called out to sh for no reason.

I'll add a test for MPR#6886 in a separate PR.

Given the state of the history, I suggest that whoever merges this (when the CIs come back green) does a squash merge.

Thanks @trefis!

I merged onto trunk. I'll let someone else cherry-pick on 4.08.

I cherry-picked the commit to 4.08

Thanks guys, now I can do the beta!