search

bmillwood / haskell-src-meta

Maintenance of Matt Morrow's package for parsing haskell source to a TH AST.
Other
27 stars 51 forks source link

compile failures in recent releases w/ GHC 7.4.2 #62

Closed hvr closed 7 years ago

hvr commented 7 years ago

See also https://matrix.hackage.haskell.org/package/haskell-src-meta

This is causing indirect failures for other packages (e.g. here or aeson-qq). From a quick glance, I'd guess that the version bounds on template-haskell (and thus effectively those on base as well) need fixing up on Hackage for the 3 releases (0.8, 0.7.01, and 0.7.0), but I haven't investigated enough to be sufficiently confident to perform the required cabal revisions:

Configuring component lib from haskell-src-meta-0.8...
Preprocessing library haskell-src-meta-0.8...
[1 of 4] Compiling Language.Haskell.Meta.Syntax.Translate ( src/Language/Haskell/Meta/Syntax/Translate.hs, /tmp/matrix-worker/1496177379/dist-newstyle/build/x86_64-linux/ghc-7.4.2/haskell-src-meta-0.8/build/Language/Haskell/Meta/Syntax/Translate.o )

src/Language/Haskell/Meta/Syntax/Translate.hs:247:40:
    Not in scope: data constructor `MultiIfE'
    Perhaps you meant `Hs.MultiIf' (imported from Language.Haskell.Exts.Syntax)

src/Language/Haskell/Meta/Syntax/Translate.hs:321:28:
    Not in scope: data constructor `StarT'
    Perhaps you meant `StarK' (imported from Language.Haskell.TH.Syntax)

src/Language/Haskell/Meta/Syntax/Translate.hs:468:25:
    Not in scope: data constructor `Inline'
    Perhaps you meant `InlineP' (imported from Language.Haskell.TH.Syntax)

src/Language/Haskell/Meta/Syntax/Translate.hs:468:32:
    Not in scope: data constructor `ConLike'

src/Language/Haskell/Meta/Syntax/Translate.hs:470:32:
    Not in scope: data constructor `FunLike'

src/Language/Haskell/Meta/Syntax/Translate.hs:472:18:
    Not in scope: data constructor `Inline'
    Perhaps you meant `InlineP' (imported from Language.Haskell.TH.Syntax)

src/Language/Haskell/Meta/Syntax/Translate.hs:472:39:
    Not in scope: data constructor `NoInline'

src/Language/Haskell/Meta/Syntax/Translate.hs:546:40:
    Not in scope: type constructor or class `Phases'

src/Language/Haskell/Meta/Syntax/Translate.hs:547:20:
    Not in scope: data constructor `AllPhases'

src/Language/Haskell/Meta/Syntax/Translate.hs:548:39:
    Not in scope: data constructor `FromPhase'

src/Language/Haskell/Meta/Syntax/Translate.hs:549:40:
    Not in scope: data constructor `BeforePhase'

src/Language/Haskell/Meta/Syntax/Translate.hs:691:17:
    Not in scope: data constructor `InfixD'
    Perhaps you meant one of these:
      `Hs.InfixA' (imported from Language.Haskell.Exts.Syntax),
      `InfixC' (imported from Language.Haskell.TH.Syntax),
      `InfixE' (imported from Language.Haskell.TH.Syntax)
mainland commented 7 years ago

Fixed in 0.8.0.1.

hvr commented 7 years ago

@mainland I'm afraid this isn't fixed yet. We still need to fix the meta-data for the 3 affected releases. Install-plans based on haskell-src-meta still keep failing for GHC 7.4.2

And in fact, releasing haskell-src-meta-0.8.0.1 was not needed. It's rather counterproductive as the only thing a release which changes only the meta-data does is to add overhead to Hackage and Cabal.

mainland commented 7 years ago

Then it would have been helpful to have had a concrete description of what was necessary for a "proper" fix.

Has anyone actually been bitten by this, or is the only visible negative effect having red in a build matrix?

Feel free to fix as you see fit.

hvr commented 7 years ago

Then it would have been helpful to have had a concrete description of what was necessary for a "proper" fix.

Fair enough. I thought it was clear from the first paragraph in the issue-report that the 3 releases needed a meta-data fix, but I guess I should take some time to write up something like a "Hackage Maintainers' Guide" (I've already started with bits of that), as it's hard to know how much Hackage maintainers are aware of the latest best practices and the rationales for those.

Anyway, I've revised the aforementioned 3 affected releases, and I hope this was the correct fix as I didn't have the time to properly investigate this:

Has anyone actually been bitten by this, or is the only visible negative effect having red in a build matrix?

Well, everyone who would try to build packages with cabal depending on hackage-src-meta with GHC 7.4 - as the solver would happily backtrack to askell-src-meta-0.8.0 - would quite likely run into this. So this definitely visible for normal users as it would happen with quite normal install-plans.

Moreover, people usually don't complain if things break for them, they instead quick to blame Cabal or Hackage, and move on to other languages and tools. The point of Hackage Trustees is to educate maintainers and help fix problems at the root before they occur, as end-users are often the least suited ones to understand what's going wrong. The matrix builder is becoming better at detecting inaccurate meta-data (which becoming more essential for cabal new-build to be able to pick sound install plans). So this will become more and more important in the future.

mainland commented 7 years ago

I would be very grateful for a best practices document. Although I maintain several packages, I don't follow the various mailing lists carefully, so I don't know what the best practices are unless they're written down in an obvious, unified place.

Concerning the matrix builder, I'll note that I do set the tested-with cabal field to match what I actually test. One could argue that if the matrix builder chooses to try something else, it gets what it deserves... Same goes for anyone attempting to use an untested compiler, including the cabal planner.

hvr commented 7 years ago

Well, the tested-with field was actually soft deprecated... Hackage doesn't show it anymore... it wasn't used consistently enough. The only tool I know which still makes use of it is my Travis CI script generator. But more importantly, cabal doesn't interpret it (if it would honor it, a lot of install-plans would suddenly break, because it's not used consistently). So yes, one could argue that the system should be redesigned to operate differently, but that's a tough sell given the amount of effort it would take to change all involved components and backward compatibility issues involved.

mainland commented 7 years ago

That would be a good thing to add to the best practices document. The cabal docs don't mention any deprecation.