Perhaps it's processed for haddock? Uploading a log might help pinpoint this. On 25/03/2026 14:14, Simon Peyton Jones via ghc-devs wrote:

PPS: but perhaps you are saying that, for inscrutable reasons, every {-# OPTIONS_GHC -fdefines-known-key-names #-} must be surrounded with #ifdef BOOSTRAP_TH? Or maybe #ifndef?

It's very mysterious that this suddenly started happening, but that's a side issue

Simon

On Wed, 25 Mar 2026 at 13:12, Simon Peyton Jones wrote:

PS:  Note [Bootstrapping Template Haskell] does not mention BOOTSTRAP_TH!

On Wed, 25 Mar 2026 at 13:08, Simon Peyton Jones wrote:

I think to avoid this you will need to be careful to only apply these flags when the BOOTSTRAP_TH flag is set. In particular, I think what's happening is that we try to find the GHC.KnownKey module and then start pulling in all of ghc-internal.

Ah yes.   The command line does indeed invoke the *bootstrap *compiler, which of course does now know these flags.

*But what business does the bootstrap compiler have with compiling GHC.Internal.Classes? * I would be entirely unsurprised if the bootstrap compiler stumbled on compiling a module that is so closely coupled to GHC's internals.

Simon

On Wed, 25 Mar 2026 at 13:02, Teo Camarasu wrote:

Hi Simon,

Note that this is occurring while compiling `ghc-boot-th-next`. This package vendors the TemplateHaskell interfaces from ghc-internal and is built by the boot compiler. You will find a bunch of CPP in the TemplateHaskell modules like `GHC.Internal.TH.Syntax` that switches out `ghc-internal` imports for `base` imports when bootstrapping so we can compile with the boot compiler. For more context see `Note [Bootstrapping Template Haskell]`.

I think to avoid this you will need to be careful to only apply these flags when the BOOTSTRAP_TH flag is set. In particular, I think what's happening is that we try to find the GHC.KnownKey module and then start pulling in all of ghc-internal.

Cheers, Teo

On Wed, 25 Mar 2026, at 12:56 PM, Brandon Allbery via ghc-devs wrote:

...

I'd suspect it's your boot compiler producing that error, and that what changed might have been the file being compiled, causing a recompile with the wrong compiler?

On Wed, Mar 25, 2026 at 8:53 AM Simon Peyton Jones via ghc-devs wrote:

Friends

After 10 days of working on !15719 I have suddenly started getting

/home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src/GHC/Internal/Classes.hs:10:17: error: [GHC-04924]     Unknown flag in  {-# OPTIONS_GHC #-} pragma: -fdefines-known-key-names    | 10 | {-# OPTIONS_GHC -fdefines-known-key-names #-}    | ^^^^^^^^^^^^^^^^^^^^^^^^^

I have no idea why this was fine until 10am this morning, and has suddenly started happening now.

*How does GHC decide what runtime flags it allows? * `-fdefines-known-key-names` is in GHC.Driver.Session.fFlagsDeps.

I'm boggled that it worked until 10am and then abruptly stopped.

Any advice?

Simon

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

But the problem is NOT with that import. It's with the OPTIONS_GHC in GHC.Internal.Classes, which is not in the external-modules section. I did as you suggested but I'm still getting the stuff below Warning: Specifying an absolute path to the project file is deprecated. Use --project-dir to set the project's directory. Configuration is affected by cabal.project at '/home/simonpj/code/HEAD-19/hadrian'. Up to date Warning: Specifying an absolute path to the project file is deprecated. Use --project-dir to set the project's directory. Configuration is affected by cabal.project at '/home/simonpj/code/HEAD-19/hadrian'. ]0;Starting...(/home/simonpj/code/HEAD-19) | Copy file: utils/haddock/haddock-api/resources/html/Classic.theme/plus.gif => _build/stage1/lib/html/Classic.theme/plus.gif | Run Ghc FindHsDependencies (Stage0 InTreeLibs): libraries/ghc-boot-th/GHC/Boot/TH/Lib.hs (and 14 more) => _build/stage0/libraries/ghc-boot-th-next/.dependencies.mk /home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src/GHC/Internal/Classes.hs:10:17: error: [GHC-04924] Unknown flag in {-# OPTIONS_GHC #-} pragma: -fdefines-known-key-names | 10 | {-# OPTIONS_GHC -fdefines-known-key-names #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^ ]0;Finished in 2.54s(/home/simonpj/code/HEAD-19) Development.Shake.cmd, system command failed Command line: /home/simonpj/.ghcup/bin/ghc -M -include-cpp-deps -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/inplace/package.conf.d' '-this-unit-id ghc-boot-th-next-9.15-inplace' '-this-package-name ghc-boot-th-next' '-package-id base-4.21.0.0-ae91' '-package-id ghc-prim-0.13.0-e168' '-package-id pretty-1.1.3.6-fe44' -i -i/home/simonpj/code/HEAD-19/_build/stage0/libraries/ghc-boot-th-next/build -i/home/simonpj/code/HEAD-19/_build/stage0/libraries/ghc-boot-th-next/build/autogen -i/home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-boot-th -i/home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src -I_build/stage0/libraries/ghc-boot-th-next/build -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-internal-9.1202.0-1465/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-bignum-1.3-6db4/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/rts-1.0.2/include -optP-include -optP_build/stage0/libraries/ghc-boot-th-next/build/autogen/cabal_macros.h -optP-DBOOTSTRAP_TH -outputdir _build/stage0/libraries/ghc-boot-th-next/build -fdiagnostics-color=always -XHaskell2010 -XNoImplicitPrelude -optc-Wno-error=inline -include-pkg-deps -dep-makefile _build/stage0/libraries/ghc-boot-th-next/.dependencies.mk -dep-suffix '' -fno-warn-deprecated-flags -O +RTS -O64M -RTS @/tmp/extra-file-89749345684126-2082901-0 Exit code: 1 Stderr: /home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src/GHC/Internal/Classes.hs:10:17: error: [GHC-04924] Unknown flag in {-# OPTIONS_GHC #-} pragma: -fdefines-known-key-names | 10 | {-# OPTIONS_GHC -fdefines-known-key-names #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^ On Wed, 25 Mar 2026 at 13:17, Teo Camarasu wrote:

...

*But what business does the bootstrap compiler have with compiling GHC.Internal.Classes? *

Aha! I see the issue.

If you look here: https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/ghc-boot-th/ghc-b...

if flag(bootstrap) cpp-options: -DBOOTSTRAP_TH build-depends: ghc-prim hs-source-dirs: @SourceRoot@ ../ghc-internal/src exposed-modules: GHC.Boot.TH.Lib GHC.Boot.TH.Syntax GHC.Boot.TH.Monad other-modules: GHC.Internal.TH.Lib GHC.Internal.TH.Syntax GHC.Internal.TH.Monad GHC.Internal.ForeignSrcLang GHC.Internal.LanguageExtensions GHC.Internal.Lexeme

You can see the modules that we vendor from `ghc-internal` under `other-modules.

One of those is `GHC.Internal.ForeignSrcLang` and in your PR you add: ``` import GHC.Internal.Classes( (==) ) -- For known-key names ``` This needs to go inside the `else` branch of the `ifdef BOOTSTRAP_TH` pragma.

I think if you do the same thing for any `ghc-internal` imports in the other modules mentioned above then you should be fine.

I really should add a note explaining this BOOTSTRAP_TH business, especially because it is quite hacky(!). Note [Bootstrapping Template Haskell] does a good job of explaining the design decisions we made to get here, but we need another note to explain this CPP soup.

Cheers, Teo

Perhaps you can look in the: _build/stage0/libraries/ghc-boot-th-next/. dependencies.mk makefile and seeing which module is bringing in this dependency and then getting rid of that edge.

Oh dear. I am WAY WAY out of my depth But then I realised that PERHAPS the issue is not - what modules are in `other-modules` but rather - what modules are *depended on* by `othher-modules` *when *BOOTSTRAP_TH is *not on.* And indeed that solved it. In ForeignSrcLang I needed to put the extra import in the branch when BOOSTRAP_TH is *off*, so that it does not depend indirectly on GHC.Internal.Classes. It's working now. Wow, that was mysterious. A writeup of BOOTSTRAP_TH would be valuable. With pointers to it from its use-sites. Thanks for helping. I would not have solved it without you. Simon On Wed, 25 Mar 2026 at 14:49, Teo Camarasu wrote:

...

But the problem is NOT with that import. It's with the OPTIONS_GHC in GHC.Internal.Classes, which is not in the external-modules section.

Indeed. Hadrian is not smart enough to give us an error here if we attempt to build a module that isn't included in the .cabal file. But if something is bringing it in while building stuff from `ghc-boot-th-next` then the error is that this module is being built. We really shouldn't be building it and we shouldn't need to. At this stage we just want to get the definitions from these TemplateHaskell files and we do not want to build large sections of `ghc-internal`.

Perhaps you can look in the: _build/stage0/libraries/ghc-boot-th-next/. dependencies.mk makefile and seeing which module is bringing in this dependency and then getting rid of that edge.