Upgrade to Cabal 2.0

[snoyberg]

Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.

Please include the following checklist in your PR:

• Any changes that could be relevant to users have been recorded in the ChangeLog.md
• The documentation has been updated, if necessary.

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

• There are spurious cyclic dependencies on this branch being detected, almost certainly due to a change in how Cabal reports dependency information. I need to track that down before merging.

[snoyberg]

@mgsloan Do you have any insight into a way to avoid having to change this hash? Unless I'm mistaken, changing it will correct the precompiled package cache.

[mgsloan]

The version tag should be bumped if the serialization has changed. I haven't looked over this change very thoroughly, but can we be sure that the serialization is the same as before? If so, then you can just change the hash and keep the version tag the same, and things should just work.

What's the motivation for switching over to Cabal types? To me it'd make sense to minimize dependencies on Cabal api.

[snoyberg]

That's unfortunate, I was hoping there was some way to add backwards-compatibility support using the old serialization format.

I understand the goal of being less dependent on the Cabal API, but I don't think it's too relevant here: we're already wrapping up these data types internally, and can easily wrap them differently in the future. The advantage is that Cabal's new representations are more space efficient (using unpinned memory and UTF-8 encoding, or in the case of Version encoding to a single Word64). But if we're going to lose caching, I'd rather just back out this change.

[mgsloan]

That's unfortunate, I was hoping there was some way to add backwards-compatibility support using the old serialization format.

That is possible, but of course the datatypes will need to be duplicated. Some logic would need to be implemented to handle recognizing the old tag and doing the datatype migration.

[felixonmars]

Sorry if it's not related: I tried to build this branch with GHC 8.2.1, but got the following errors:

src/Stack/Build/Cache.hs:110:55: error:
    • Exception when trying to run compile-time code:
        For Stack.Types.Build.BuildCache,
Data.Store.Version expected hash "IwLXp-Y9VptuI0_MD15kAGNLLZQ=", but "KVUoviSWWAd7tiRRGeWAvd0UIN4=" is specified.
The data used to construct the hash has been written to "/build/stack/src/stack-1.5.1.20170817/dist/store-versioned/IwLXp-Y9VptuI0_MD15kAGNLLZQ=", but no file found with previously stored structural info.

CallStack (from HasCallStack):
  error, called at src/Data/Store/Version.hs:120:21 in store-0.4.3.1-71dSdJpoHkp2Pb7UJRNG57:Data.Store.Version
      Code: versionedDecodeFile buildCacheVC
    • In the untyped splice: $(versionedDecodeFile buildCacheVC)
    |
110 | tryGetBuildCache dir = liftM (fmap buildCacheTimes) . $(versionedDecodeFile buildCacheVC) =<< buildCacheFile dir
    |                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[snoyberg]

@felixonmars Thanks for the feedback, but we're not going to be upgrading to GHC 8.2 quite yet. That will be undertaken later.