Haddock flags precedence and local override

[guibou]

The rational behinds is that haddocks_flags can be used to override compiler_flags. For example, if compiler_flags uses -Werror, we may want to disable it using -Wwarn in haddock_flags to allows non-fatal warnings.

Future haddock version will support -Werror in haddock.

[picnoir]

FYI, using args.add in order to append a list has been deprecated. This will result in an error in a future Bazel release. We should use ghc_args.add_all() instead.

See https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#new-args-api

[guibou]

Thank you. Fixed.

[Profpatsch]

LGTM after switching to add_all.

[guibou]

@Profpatsch if you can redo a review, I pushed a new commit which also add custom haddock flag per rule.

[mboes]

The latter change I object to. We have separate documentation targets. Those alone should encapsulate all documentation concerns from the moment they exist.

[guibou]

@mboes what do you suggest?

Use case, we use -Werror on all haddock rules, set in haskell_toolchain/haddock_rules, but one haskell_library documentation fails because of a documentation error we don't care about for now, so we want to switch to -Wwarn for that rule only. This is a real use case I have now.

[mboes]

If haskell_doc is composable (if it's not, then it should be made so), then you can deal with your use case like this:

haskell_doc(
  name = ":some_haskell_lib_doc",
  deps = [":some_haskell_lib"],
  haddock_flags = ["-Wwarn"],
)

haskell_doc(
  deps = [":another_lib", ":yet_another_lib", ":some_haskell_lib_doc"],
)

[guibou]

haskell_doc does not have haddock_flags, they are in haskell_toolchain for simplicity reason.

Should I revert this change in the hope that someone will later introduces the change you propose in haskell_doc?

[mboes]

Should I revert this change in the hope that someone will later introduces the change you propose in haskell_doc?

There are two commits in this PR. The first is fine and the second is controversial. Therefore, merge the first one, drop the second one and create a ticket for a composable haskell_doc. If it's relevant for your use case go ahead with the implementation of that ticket.

[guibou]

I just opened #583, could you please complete it with your design ideas and technical solutions.

[Profpatsch]

Okay, let’s discuss the change there and we can merge this .