Error parsing if/else block in test-suite stanza of cabal file

[nghamilton]

Using an if/else block to provide alternative main-is values in the test-suite stanza results in a parsing error:

Test suite "cabal-bug" is missing required field "type" or the field is not present in all conditional branches.

Minimal reproducible example.

A workaround is to include type field in both branches, as suggested by the error message:

  if flag(breaks)
    main-is:         Main1.hs
    type:            exitcode-stdio-1.0
  else
    main-is:         Main2.hs
    type:            exitcode-stdio-1.0

If this is the expected behavior, the error message could possibly be expressed more clearly, or the documentation could state the type field should be present in all conditional branches.

Tested on cabal version 3.0.0.

[m-renaud]

Digging into the parsing it appears this happens due to the two pass nature of how the parsing is written. The testSuiteFieldGrammar will only parse a top level main-is, it won't look into conditional blocks which leaves the _testStanzaMainIs field as Nothing. Then, when constructing the TestSuite record it leaves the testInterface unset because there isn't a main-is file available (see validateTestSuite).

To fix this we would need to change the validation to not use traverse but instead have a stateful traversal which combines context from different levels in the conditional tree. Another alternative would be to allow a half-filled TestSuiteInterface that only has the type, and then allow main-is to be filled in by the conditional branches.

I also noticed that TestSuiteInterface has a file associated with the type (the main-is value), but this doesn't really make sense in a situation where there are multiple possible main-is modules.

[phadej]

I'd rather clearly disallog main-is inside conditional blocks.

The "limitation" can be simply enough worked around by e.g.

main-is: Main.hs
if flag(doesnt-break)
  other-modules: Module1
else
  other-modules: Module2

It's simpler that way, and consistent with e.g. type, which more clearly doesn't make sense to be conditional.

To avoid confusion main-is should specified exactly once per conditionals. In the example above it's true:

example 2:

Still: main-is is unique, but is not that obvious from the structure.
You have to expect condition expressins:

if flag(flag1) && flag(flag2)
  main-is: Main1.hs

if !flag(flag1)
  main-is: Main2.hs
else
  main-is: Main3.hs

example 3

This is confusing behavior, which wouldn't work.
Search issue tracker for buildable. In fact, we should warn
when buildable is set more than once per branch too.
That we have to support as it's used on Hackage.

if flag(something)
  main-is: DifferentMain

main-is: DefaultMain

Conclusion

In other words, it's technically possible to implement, but tricky.
So I'd rather improve the error messages. The complication doesn't pull
its weight.