Dune treats warnings as errors according to the workspace `lang dune` version when building vendored packages with a more permissive `lang dune` version
Nobody has claimed this yet.
- Dominant language
- OCaml
- Stars
- 1.9k
- Forks
- 500
- Avg merge
- 15h 21m
- Merged PRs (30d)
- 277
Description
Expected Behavior
When compiling vendored packages, dune should act like the version specified in dune lang in the dune-project file when determining which warnings should be treated as errors.
Actual Behavior
Dune appears to determine which warnings should be treated as errors based on the dune lang version in the top-level dune-project when compiling vendored libraries.
Reproduction
Here's a simple repro of this issue
It looks like between dune 3.2 and 3.3 dune was changed to treat warning 69 (declaring a mutable record field which is never mutated) as an error whereas it was previously just a warning. The top-level dune-project uses dune lang 3.6 but the vendored package (resource-pooling) uses dune lang 1.11, and running dune build gives the error:
File "vendored/resource-pooling/resource_pool.ml", line 21, characters 2-27:
21 | mutable node_prev : 'a t;
^^^^^^^^^^^^^^^^^^^^^^^^^
Error (warning 69 [unused-field]): mutable record field node_prev is never mutated.
File "vendored/resource-pooling/resource_pool.ml", line 22, characters 2-27:
22 | mutable node_next : 'a t;
^^^^^^^^^^^^^^^^^^^^^^^^^
Error (warning 69 [unused-field]): mutable record field node_next is never mutated.
But if we take the source of resource-pooling by itself, it builds with a warning instead.
The reverse situation also causes unexpected behaviour. If we modify resource-pooling to use dune lang 3.6 it no longer builds as warning 69 is now an error, but if we vendor the modified resource-pooling in a project using dune lang 3.2 or below then it builds with a warning.
Specifications
- Version of
dune(output ofdune --version): 3.6.1 - Version of
ocaml(output ofocamlc --version): 5.0.0 - Operating system (distribution and version): nixos
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked reproduction and compare the top-level dune-project's language version with the vendored resource-pooling package's dune language version. Trace how dune build determines warning severity for each package; done means vendored packages use their own declared language version when deciding whether warning 69 is an error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ocaml
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100