Make type field optional for tests and benchmarks

[cydparser]

Resolves #7459

I manually tested the change using cabal check against the various combinations of fields and stanzas.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

[Mikolaj]

Well done! A quick git grep exitcode-stdio shows there's a lot of tests with this field. I wonder, perhaps you could pick a couple of such tests, maybe best if they have some very similar counterparts in the test suite, and remove the field in them (but not in the counterparts, to keep testing the parsing of the field in the same context) and tweak the expected outputs accordingly? We may want to avoid tests that specifically test the testing harness so as not to derail their main purpose.

[cydparser]

Thanks @Mikolaj. I've done as you suggested and removed type from some tests. I've also fixed the failing #5055 tests, but wonder whether they should be removed instead.

[Mikolaj]

fixed the failing #5055 tests, but wonder whether they should be removed instead.

As far as I understand, these tests really do test the changed functionality, so I'd keep them. I can't say I understand the functionality well, though (#5055), but perhaps we shouldn't worry too much.

removed type from some tests

Perfect. CI broke randomly, so let me restart.

[Mikolaj]

@Mergifyio rebase

[mergify]

rebase

☑️ Nothing to do

• -closed [:pushpin: rebase requirement]
• #commits-behind>0 [:pushpin: rebase requirement]

[Mikolaj]

The same CI failure (Windows: Access violation in generated code when reading 0xffffffffffffffff) and the same cancellation of jobs without an obvious reason. Github status is green, but I suspect github outage, regardless. No other cabal CI jobs running right now to compare to, so I've rebased PR #8038 to compare to. Let's see how it goes.

[Mikolaj]

Copying from #hackage:

is it possible this is a genuine linker/libs/whatever error and the other jobs got cancelled, because GHA is smart and noticed the required job that depends on all of them won't be green anway, due to this single failure?

(the jobs that got cancelled are not required, but they are dependencies of a required job AFAICT)

the disaster just got completely reproduced in another PR I just rebased

given that it's Windows and the relatively old GHC 8.4.4 I vote to disable this CI job with a "fluke" comment and worry only if it repeats for any other job

Once we disable the offending CI job, let's rebase to repeat the tests.

[Mikolaj]

@Mergifyio rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Mikolaj]

Splendid. Now CI green. :)

[Mikolaj]

LGTM

[jneira]

looks good, that is a sensible default, thanks!

[fgaz]

This changes the cabal spec, and needs a changelog entry and version guards, or we'll have to revert before release.

[Mikolaj]

Details for the 3.8 TODO:

The changelog in question is https://github.com/haskell/cabal/blob/master/doc/file-format-changelog.rst

The code change may be something like #8134 and #8135 (when done.

[andreasabel]

Changes requested: Clarification concerning cabal-version needed.