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
Differential Rev(s): | → https://gitlab.haskell.org/ghc/ghc/merge_requests/383 |
---|---|
Milestone: | → 8.8.1 |
Status: | new → merge |
Fixed in ee284b854e514685036dc21a1ee61241c76d14b5. Marking as a merge candidate for 8.8.