Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

melange: add test to reproduce "inconsistent assumptions" issue when using melange ppx #7323

Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
103 changes: 103 additions & 0 deletions test/blackbox-tests/test-cases/melange/library-cmi-consistency.t
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
Test to showcase "inconsistent assumption" issues when using melange ppx

$ cat > dune-project <<EOF
> (lang dune 3.7)
> (using melange 0.1)
> EOF

$ cat > dune <<EOF
> (melange.emit
> (target output)
> (alias mel)
> (libraries my_lib))
> EOF

$ mkdir lib
$ cat > lib/dune <<EOF
> (library
> (name my_lib)
> (modes melange))
> EOF

$ cat > main.ml <<EOF
> let t = My_lib.A.t
> let u = My_lib.B.t
> EOF

$ cat > lib/a.ml <<EOF
> let t = D.t
> let u = C.t
> EOF

$ cat > lib/b.ml <<EOF
> let t = [%bs.obj { a = C.t }]
> EOF

$ cat > lib/c.ml <<EOF
> type t = < a : D.t >
> let t: < a : D.t > = [%bs.obj { a = D.t }]
> EOF

$ cat > lib/d.ml <<EOF
> type t = string
> let t = "bar"
> EOF

$ dune build @mel
File "lib/b.ml", line 1, characters 23-26:
1 | let t = [%bs.obj { a = C.t }]
^^^
Error: The module C is an alias for module My_lib__C, which is missing
[1]

Now change D which is a leaf in the dep tree, notice error on revdeps A (direct)
and B (transitive)

$ cat > lib/d.ml <<EOF
> type t = int
> let t = 2
> EOF

$ dune build @mel
File "_none_", line 1:
Error: My_lib__C not found, it means either the module does not exist or it is a namespace
File "main.ml", line 1:
Error: The files lib/.my_lib.objs/melange/my_lib__A.cmi
and lib/.my_lib.objs/melange/my_lib__B.cmi
make inconsistent assumptions over interface My_lib__D
[1]

Replacing modules with melange-ppx-less code fixes the issue

$ cat > lib/b.ml <<EOF
> let t = C.t
> EOF

$ cat > lib/c.ml <<EOF
> type t = D.t
> let t: D.t = D.t
> EOF

$ dune build @mel

Also, using disabling melange builtin ppx and using preprocess fixes the problem

$ cat > lib/b.ml <<EOF
> let t = [%bs.obj { a = C.t }]
> EOF

$ cat > lib/c.ml <<EOF
> type t = < a : D.t >
> let t: < a : D.t > = [%bs.obj { a = D.t }]
> EOF

$ cat > lib/dune <<EOF
> (library
> (name my_lib)
> (preprocess
> (action (run melc --as-pp %{input-file})))
> (melange.compile_flags :standard --bs-no-builtin-ppx)
> (modes melange))
> EOF

$ dune build @mel