Opened 10 months ago

Last modified 6 months ago

#16331 merge bug

REGRESSION: --supported-languages lies about supported languages, again

Reported by: hvr Owned by:
Priority: highest Milestone: 8.8.1
Component: Compiler Version: 8.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): https://gitlab.haskell.org/ghc/ghc/merge_requests/383
Wiki Page:

Description

To make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-(

Basically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you enable it via {-# LANGUAGE ... #-} or -X-flags. Otherwise this breaks the whole idea of other-extensions and related cabal spec features which use --supported-languages to infer whether e.g. GHC when invoked with -XTemplateHaskell will succeed.

However, consider the Main.hs below

{-# LANGUAGE TemplateHaskell #-}

main = $undefined

Unfortuantely now GHC lies unconditionally about supporting TH, thereby undermining the infrastructure we setup in and for #11102:

$ ghc --supported-languages | grep ^TemplateHaskell$
TemplateHaskell

$ ghc --make Foo.hs 
[1 of 1] Compiling Main             ( Foo.hs, Foo.o )
ghc-stage2: this operation requires -fexternal-interpreter

Change History (3)

comment:1 Changed 10 months ago by RyanGlScott

Differential Rev(s): https://gitlab.haskell.org/ghc/ghc/merge_requests/383
Milestone: 8.8.1
Status: newmerge

Fixed in ee284b854e514685036dc21a1ee61241c76d14b5. Marking as a merge candidate for 8.8.

comment:2 Changed 9 months ago by Marge Bot <ben+marge-bot@…>

In ee284b85/ghc:

Fix regression incorrectly advertising TH support

`--supported-languages` must only advertise language extensions
which are supported by the compiler in order for tooling such
as Cabal relying on this signalling not to behave incorrectly.

Fixes #16331

comment:3 Changed 6 months ago by Marge Bot <ben+marge-bot@…>

In 39f50bf/ghc:

Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETER

As discussed in #16331, the GHCI macro, defined through 'ghci' flags
in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
whether GHC is built with support for an internal interpreter, that runs in
the same process. It is however overloaded in a few places to mean
"there is an interpreter available", regardless of whether it's an internal
or external interpreter.

For the sake of clarity and with the hope of more easily being able to
build stage 1 GHCs with external interpreter support, this patch splits
the previous GHCI macro into 3 different ones:

- HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
- HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
- HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
Note: See TracTickets for help on using tickets.