#8176 closed bug (fixed)

Language extensions not registered

Reported by: duncan Owned by: thoughtpolice
Priority: normal Milestone: 7.8.1
Component: Compiler Version: 7.7
Keywords: Cc: hvr
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: tests/driver/T4437.hs
Blocked By: Blocking:
Related Tickets: Differential Revisions:


tests/driver/T4437.hs does not seem to be being used properly.

That test is there to make sure that ghc developers do not forget to register their new extensions with Cabal. But it looks like it's just being silenced and they are being forgotten again.

Recall, the protocol is that all Haskell implementations can register their extensions in the central location (which is Language.Haskell.Extensions in the Cabal package) when they are happy that they are ready for public consumption. This matters to users because extensions that are not ready for public consumption (ie not registered) cannot be used in packages uploaded to hackage.

Currently tests/driver/T4437.hs contains:

expectedGhcOnlyExtensions = [

This looks like a much bigger list than it should be. Surely not all of these extensions are private to ghc or are still under development and not to be used?

But if they are listed here, then the test doesn't complain about them. And the whole point of this test is to stop ghc devs from forgetting to register them.

I think we need to change the test so that we distinguish between extensions that are really not ready, and ones that are on-track to be public. It should be a release blocker for the "on-track to be public" ones to still not be registered. The test should have comments giving this guidance for ghc contributors.

I'm not quite sure how we adjust the test to make that happen (ie different behaviour for RC-build vs normal hacking validate).

Change History (9)

comment:1 Changed 19 months ago by hvr

  • Cc hvr added
Version 0, edited 19 months ago by hvr (next)

comment:2 Changed 19 months ago by simonpj

I think that the underlying difficulty is that we don't have a clearly-articulated protocol. What, step by step, should a GHC developer do when adding an extension? The steps should cover what happens in the intervening bit, when the extension isn't in Cabal but is in GHC... we don't want validate to fail at that point.

I think if we laid out some steps (and pointed to them from the test) it'd be much more likely to happen.

Thanks, Simon

comment:3 Changed 19 months ago by hvr

...while we're at it; as cabal-1.18 is in RC-mode right now for a couple of days: which of the above listed ghc-only extensions are deemed worthy for public consumption in GHC 7.8 and shall be made known to to the final release of Cabal-1.18.0?

comment:4 Changed 19 months ago by dreixel

I think AutoDeriveTypeable is.

comment:5 Changed 19 months ago by simonpj

I've just checked, and added some missing documentation. My resulting list is this:

  I have no idea about these three.  Need input from Ian


  Yes (allows you to say 'type (+)' in import/export lists)








comment:6 Changed 19 months ago by duncan

So comparing with what we comitted during the recent Zurich hackathon: https://github.com/haskell/cabal/commit/d40207efec3133735cee89aec17974ea6c307613

  • OverloadedLists
  • EmptyCase
  • AutoDeriveTypeable
  • NegativeLiterals
  • NumDecimals
  • NullaryTypeClasses

We added all these because they were documented in the user guide already.

We didn't add TypeHoles on the theory that it would not be used in released packages. However on reflection it would be better to add it as a registered extension but to have an explicit check for it not being used in distributed packages (e.g. like we complain about -Werror).

So what are we still missing then?

  • ExplicitNamespaces
  • AllowAmbiguousTypes

We should check these are documented in the user guide and then register them in Language.Haskell.Extensions.

comment:7 Changed 19 months ago by duncan

And Simon is right of course about documenting the procedure. I suggest the test case link to a page in the ghc wiki which describes the process clearly.

comment:8 Changed 19 months ago by hvr

Fyi, Simon added documentation (including the 3 outstanding extensions) via d5b81cb387ceb8e717828047edc52586d4bc19bb

comment:9 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.8.1
  • Resolution set to fixed
  • Status changed from new to closed

This is now all cleaned up and fixed.

Note: See TracTickets for help on using tickets.