Opened 4 years ago

Closed 20 months ago

#8176 closed task (fixed)

Language extensions not registered

Reported by: duncan Owned by:
Priority: normal Milestone:
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 Rev(s):
Wiki Page:


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 (18)

comment:1 Changed 4 years ago by hvr

Cc: hvr added
Version 0, edited 4 years ago by hvr (next)

comment:2 Changed 4 years 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 4 years 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 4 years ago by dreixel

I think AutoDeriveTypeable is.

comment:5 Changed 4 years 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 4 years ago by duncan

So comparing with what we comitted during the recent Zurich hackathon:

  • 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 4 years 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 4 years ago by hvr

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

comment:9 Changed 3 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

This is now all cleaned up and fixed.

comment:10 Changed 2 years ago by thomie

Keywords: newcomer added
Owner: thoughtpolice deleted
Resolution: fixed
Status: closednew

Task for a newcomer.

testsuite/tests/driver/T4437.hs currently contains:

 expectedGhcOnlyExtensions :: [String]
 expectedGhcOnlyExtensions = ["RelaxedLayout",

The last 2 extensions should be registered with Cabal. Submit a pull request to

I don't know what the first 3 are about, they are not listed on Try to find out if they can be deleted.

comment:11 Changed 2 years ago by thomie

Type: bugtask

comment:12 Changed 2 years ago by thomie


comment:13 Changed 2 years ago by thomie

Keywords: newcomer removed

comment:14 in reply to:  10 Changed 2 years ago by hvr

Replying to thomie:

I don't know what the first 3 are about, they are not listed on Try to find out if they can be deleted.

That very question comes up before every major GHC release ;-)

See e.g.

short answer: those are not considered official yet

comment:15 Changed 22 months ago by bgamari

I have opened #11359 to track the potential removal of these three layout language extensions.

comment:16 Changed 22 months ago by Ben Gamari <ben@…>

In 7861a225/ghc:

Add a note describing the protocol for adding a language extension

Reviewers: hvr, thomie, austin

Reviewed By: austin

Subscribers: duncan

Differential Revision:

GHC Trac Issues: #8176, #4437

comment:17 Changed 21 months ago by thomie

Milestone: 8.0.1

comment:18 Changed 20 months ago by thomie

Resolution: fixed
Status: newclosed

This issue is now tracked in #11359.

Note: See TracTickets for help on using tickets.