caret operator accepts a set of versions

[tseenshe]

I've found the ^>= operator to be quite verbose to use when I am supporting multiple ghcs (or stackage snapshots). I found this cool post from ages ago https://www.reddit.com/r/haskell/comments/7tykqi/should_stackage_ignore_version_bounds/dtgp0v0 which looked good. e.g.

  build-depends: network ^>= { 2.6.3.6, 2.7.0.2, 2.8.0.0, 3.0.1.0 }

I don't know how to write a test. Somebody please help?

---

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.

Please also shortly describe how you tested your change. Bonus points for added tests!

[phadej]

@tseenshe look at leading-comma tests in https://github.com/haskell/cabal/tree/master/Cabal/tests/ParserTests/errors and https://github.com/haskell/cabal/tree/master/Cabal/tests/ParserTests/regressions

(note that only .cabal file is written, others are --accepted when run the test-suite).

And after you make a first commit, you'll need to make gen-extra-source-files to populate extra-source-files field in Cabal.

[phadej]

@hvr if you look at this, this doesn't differentiate between 01.02.03 and 1.2.3 given different cabal-version.

I'll change that, hopefully nothing slipped on Hackage

http://hackage.haskell.org/package/Cabal-2.4.1.0/docs/src/Distribution.Types.Version.html#line-99

[hvr]

See also #5138 where we took some measures to prevent denorm versions hitting hackage

[phadej]

ooh, hmm...

@hvr should we introduce a VersionRange constructor for set notation? I'd say yes. And can do it after this is merged.

[phadej]

We'd need NonEmpty to do it, so it's "a bit" tricky

[hvr]

The main benefit would be for syntactical round tripping, wouldn't it? Don't we already have other cases such as -none where we have a syntactically lossy encoding?

I wonder if we should instead go for having two different datatypes, one for the concrete parsetree (which is better for error reporting and/or pretty printing), and one for the desugared abstract syntax tree (which is more convenient for computations). The current VersionRange type is a bit inconsistent in this regard IMO (i.e. it has support for representing parens which are imo redundant for an expression tree, but otoh it lacks the ability to represent -none directly).

In any case, I think we should discuss this in a new separate "design ticket" and we also still have the issue of having to handle pkg-config version-ranges which might be related.

[hvr]

lgtm