Stop changing the default warning set of the compiler

[nojb]

This PR follows the discussion in #8645 (comment) and in many other places.

It makes so that starting in version 3.21 of the Dune language, Dune no longer changes the warning set of the compiler. Instead, a variable of "recommended" warnings %{dune-warnings} is made available for interested users (see test).

[rgrinberg]

I think this value should not be dependant on the profile. The users can already insert this under dev in the env stanza.

[nojb]

Good point. Fixed in 68caf05

[Alizter]

Needs a changes entry and an update to the documentation.

[nojb]

Needs a changes entry and an update to the documentation.

Changes entry done. Which documentation should I look at?

[Alizter]

Here are a few places I could find:

• faq.rst has some discussion about warnings.
• variables.rst could use an update together with introduced version
• overview.rst has mention of "strict" warnings that might need updating

[nojb]

Here are a few places I could find:

Thanks for the pointers. I updated what I could. The doc about the new variable renders as thus:

[nojb]

Some of the NIX tests need investigating (maybe the failures are normal and the tests just need updating), but I don't have a NIX environment at hand...

[Alizter]

You should be able to run the tests without nix using the opam setup. The test failures should mostly be the same.

[nojb]

You should be able to run the tests without nix using the opam setup. The test failures should mostly be the same.

Thanks. The test failures revealed a small bug, which is fixed in 9ac4ca7

[rgrinberg]

Since dune itself is already using 3.21, you should use %{dune-warnings} in our root dune file.

[nojb]

Good catch. Fixed in 5c4861b

[maiste]

I'm not involved actively in the dune release management process anymore but I would advice to delay this for after the 3.21 release. There is a bigger delay than usual for the release. From my experience, it means there will already be a lot of risk of breaking packages. I would keep this for a 3.22 version, which would contain this specific change. It would allow the dune team to make sure it doesn't break any package, give time to user to adapt (by announcing it in advance), and provide the functionalities from the 3.21 without waiting.

If it may help with this change and make it smoother 🤗

Thanks @nojb for tackling this subject 😁

[Alizter]

Since this doesn't affect the release profile, I am less worried about breaking packages. If it does end up being problematic for whatever reason we can always revert, however I think that is unlikely.

[nojb]

@rgrinberg Are you happy with the present state of the PR?

[aguluman]

Starting with version 3.21 of the Dune language, Dune no longer changes the
default set of compiler warnings. For users that would like to keep the old
behaviour, the variable %{dune-warnings} can be used in the (flags) field.

Hello, a rookie here.
If I don't attach %{dune-warnings} will I stop receiving [unused-var] and other warnings as errors in my dune build flow?
Trying to understand, apologies if you have to repeat yourself another time.

[nojb]

If I don't attach %{dune-warnings} will I stop receiving [unused-var] and other warnings as errors in my dune build flow?

Yes, if you have (lang dune 3.21) (or later) in your dune-project.

[Alizter]

And just to be clear, if you are using (lang dune 3.20) or lower, even with a newer dune you won't see any difference.

[aguluman]

And just to be clear, if you are using (lang dune 3.20) or lower, even with a newer dune you won't see any difference.

Thanks for this information.
I currently have 3.20.2

How about what Nicolas said regarding using a dune version of 3.21 and needing %{dune-warnings}
I will still be getting [unused-*] as default?