Opened 8 months ago

Last modified 8 months ago

#8176 new bug

Language extensions not registered

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

Description

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 = [
                             "AllowAmbiguousTypes",
                             "RelaxedLayout",
                             "AlternativeLayoutRule",
                             "AlternativeLayoutRuleTransitional",
                             "ExplicitNamespaces",
                             "TypeHoles",
                             "OverloadedLists",
                             "EmptyCase",
                             "AutoDeriveTypeable",
                             "NegativeLiterals",
                             "NullaryTypeClasses"]

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

comment:1 Changed 8 months ago by hvr

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

comment:2 Changed 8 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 8 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 8 months ago by dreixel

I think AutoDeriveTypeable is.

comment:5 Changed 8 months ago by simonpj

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

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


AllowAmbiguousTypes
  Yes

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

TypeHoles
  Yes

OverloadedLists
  Yes

EmptyCase
  Yes

AutoDeriveTypeable
  Yes

NegativeLiterals
  Yes

NullaryTypeClasses
  Yes

Simon

comment:6 Changed 8 months ago by duncan

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

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?

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

comment:7 Changed 8 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 8 months ago by hvr

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

Note: See TracTickets for help on using tickets.