Opened 5 years ago

Closed 4 years ago

#10279 closed bug (wontfix)

panic on haskell-src-exts

Reported by: throwaway123 Owned by: ezyang
Priority: normal Milestone: 8.0.1
Component: Template Haskell Version: 7.10.1
Keywords: Cc: ezyang, osa1
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1342
Wiki Page:

Description (last modified by bgamari)

Compiling Bug.hs:

{-# LANGUAGE QuasiQuotes #-}

import Language.Haskell.Exts.QQ (dec)

main :: IO ()
main = return ()
  where 
    foo = [dec| bar = 3 |]

by ghc --make -v -dcore-lint Bug.hs gives

ghc --make -v -dcore-lint Bug.hs 
Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.4
Using binary package database: /usr/lib/ghc-7.10.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67
wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b
wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: 
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67
wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b
wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Bug.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
  [NONREC
      ModSummary {
         ms_hs_date = 2015-04-09 10:01:43.312180074 UTC
         ms_mod = Main,
         ms_textual_imps = [import (implicit) Prelude,
                            import Language.Haskell.Exts.QQ ( dec )]
         ms_srcimps = []
      }]
*** Deleting temp files:
Deleting: 
compile: input file Bug.hs
Created temporary directory: /tmp/ghc7356_0
*** Checking old interface for Main:
[1 of 1] Compiling Main             ( Bug.hs, Bug.o )
*** Parser:
*** Renamer/typechecker:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package ghc-prim-0.4.0.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS --print-file-name libgmp.so
Loading package integer-gmp-1.0.0.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
Loading package array-0.5.1.0 ... linking ... done.
Loading package filepath-1.4.0.0 ... linking ... done.
Loading package deepseq-1.4.1.1 ... linking ... done.
Loading package time-1.5.0.1 ... linking ... done.
Loading package bytestring-0.10.6.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name librt.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libutil.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libdl.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libpthread.so
Loading package unix-2.7.1.0 ... linking ... done.
Loading package directory-1.2.2.0 ... linking ... done.
Loading package old-locale-1.0.0.7 ... linking ... done.
Loading package old-time-1.1.0.3 ... linking ... done.
Loading package text-1.2.0.4 ... linking ... done.
Loading package polyparse-1.11 ... linking ... done.
Loading package cpphs-1.19 ... linking ... done.
Loading package pretty-1.1.2.0 ... linking ... done.
Loading package haskell-src-exts-1.16.0.1 ... linking ... done.
Loading package syb-0.4.4 ... linking ... done.
Loading package template-haskell-2.10.0.0 ... linking ... done.
Loading package transformers-0.4.2.0 ... linking ... done.
Loading package mtl-2.2.1 ... linking ... done.
Loading package nats-1 ... linking ... done.
Loading package th-lift-0.7.2 ... linking ... done.
Loading package containers-0.5.6.2 ... linking ... done.
Loading package safe-0.3.8 ... linking ... done.
Loading package th-expand-syns-0.3.0.6 ... linking ... done.
Loading package th-reify-many-0.1.3 ... linking ... done.
Loading package th-orphans-0.11.1 ... linking ... done.
Loading package haskell-src-meta-0.6.0.9 ... linking ... done.
Loading package haskell-src-exts-qq-0.6.1 ... linking ... done.

Bug.hs:8:16:*** Deleting temp files:
Deleting: /tmp/ghc7356_0/ghc7356_1.s
Warning: deleting non-existent /tmp/ghc7356_0/ghc7356_1.s
*** Deleting temp dirs:
Deleting: /tmp/ghc7356_0
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-unknown-linux):
	qual_pkg haskell-src-exts-1.16.0.1

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

on my machine:

$ uname -a
Linux io 3.19.3-1-ARCH #1 SMP PREEMPT Thu Mar 26 14:56:16 CET 2015 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20150304 (prerelease) (GCC)

$ ghc-pkg list
/usr/lib/ghc-7.10.1/package.conf.d
   Cabal-1.22.2.0
   array-0.5.1.0
   async-2.0.2
   base-4.8.0.0
   bin-package-db-0.0.0.0
   binary-0.7.3.0
   bytestring-0.10.6.0
   containers-0.5.6.2
   cpphs-1.19
   deepseq-1.4.1.1
   directory-1.2.2.0
   filepath-1.4.0.0
   ghc-7.10.1
   ghc-paths-0.1.0.9
   ghc-prim-0.4.0.0
   haddock-api-2.16.0
   haddock-library-1.2.0
   haskeline-0.7.2.1
   haskell-src-exts-1.16.0.1
   haskell-src-exts-qq-0.6.1
   haskell-src-meta-0.6.0.9
   hoopl-3.10.0.2
   hpc-0.6.0.2
   integer-gmp-1.0.0.0
   minisat-0.1.1
   mtl-2.2.1
   nats-1
   old-locale-1.0.0.7
   old-time-1.1.0.3
   polyparse-1.11
   pretty-1.1.2.0
   process-1.2.3.0
   rts-1.0
   safe-0.3.8
   satchmo-core-0.8.0
   stm-2.4.4
   syb-0.4.4
   template-haskell-2.10.0.0
   terminfo-0.4.0.1
   text-1.2.0.4
   th-expand-syns-0.3.0.6
   th-lift-0.7.2
   th-orphans-0.11.1
   th-reify-many-0.1.3
   time-1.5.0.1
   transformers-0.4.2.0
   unix-2.7.1.0
   xhtml-3000.2.1

Change History (38)

comment:1 Changed 5 years ago by simonpj

Cc: ezyang added

It looks as if somehow haskell-src-exts-1.16.0.1 isn't in GHC's package database, despite the fact that there's a message saying it has been loaded.

Edward might you have some idea?

Simon

comment:2 Changed 5 years ago by osa1

I think I also discovered this bug, here's my program to reproduce it: https://gist.github.com/osa1/4fe6a09a473dcb72798e (you can see also the error message in that link)

comment:3 Changed 5 years ago by ezyang

Owner: set to ezyang
Last edited 5 years ago by ezyang (previous) (diff)

comment:4 Changed 5 years ago by ezyang

I can fix the proximal error fairly easily; just remove the unconditional lookup from mkQualPackage. I'm less clear why haskell-src-exts is not in the database.

comment:5 in reply to:  4 Changed 5 years ago by simonpj

Replying to ezyang:

I can fix the proximal error fairly easily; just remove the unconditional lookup from mkQualPackage. I'm less clear why haskell-src-exts is not in the database.

It'd be great to find out! It's very mysterious (to me).

S

comment:6 Changed 5 years ago by ezyang

OK, did some reading of haskell-src-exts-qq and it's the same problem as https://github.com/ekmett/lens/issues/496 and #9745:

-- | The generic functions in 'Language.Haskell.TH.Quote' don't use global
-- names for syntax constructors. This has the unfortunate effect of breaking
-- quotation when the haskell-src-exts syntax module is imported qualified.
-- The solution is to set the flavour of all names to 'NameG'.
qualify :: Name -> Name
-- Need special cases for constructors used in string literals. Assume nearly
-- all else is a datatype defined in Syntax module of haskell-src-exts.
qualify n | ":" <- nameBase n = '(:)
          | "[]" <- nameBase n = '[]
          | "(,)" <- nameBase n = '(,)
          | "Nothing" <- nameBase n = 'Nothing
          | "Just" <- nameBase n = 'Just
          | "SrcLoc" <- nameBase n = 'Hs.SrcLoc
          | "Boxed" <- nameBase n = 'Hs.Boxed
          | otherwise = Name (mkOccName (nameBase n)) flavour
    where pkg = "haskell-src-exts-" ++ VERSION_haskell_src_exts
          flavour = NameG VarName (mkPkgName pkg)
                    (mkModName "Language.Haskell.Exts.Syntax")

This is not going to work with package keys.

It seems pretty clear to me that we should improve the error message in this case, though it's not altogether clear where it should live (probably the TH code?)

comment:7 Changed 5 years ago by ezyang

OK, it looks like at some point between 7.10 and HEAD the error message got better. But I don't know what the proximal commit was:

[ezyang@hs01 th]$ /home/hs01/ezyang/ghc-quick/inplace/bin/ghc-stage2 --interactive T10279.hs -XTemplateHaskell
GHCi, version 7.11.20150417: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling T10279           ( T10279.hs, interpreted )

T10279.hs:5:10: error:
    Failed to load interface for ‘A’
    no package matching ‘base-4.8.1.0’ was found
    In the expression: (base-4.8.1.0:A.Foo)
    In an equation for ‘blah’: blah = (base-4.8.1.0:A.Foo)

[ezyang@hs01 th]$ /home/hs01/ezyang/ghc-7.10/inplace/bin/ghc-stage2 --interactive T10279.hs -XTemplateHaskell
GHCi, version 7.10.0.20150317: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling T10279           ( T10279.hs, interpreted )

T10279.hs:5:8:ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.10.0.20150317 for x86_64-unknown-linux):
        qual_pkg base-4.8.1.0

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

The error message is still pretty confusing but at least it is not a panic.

comment:8 Changed 5 years ago by ezyang

Here is an easy new error message we can do:

testsuite/tests/th/T10279.hs:5:10: error:
    Failed to load interface for ‘A’
    no package key matching ‘base-4.8.1.0’ was found
    (This package key looks like the source package ID;  
     the real package key is ‘base’)
    In the expression: (base-4.8.1.0:A.Foo)
    In an equation for ‘blah’: blah = (base-4.8.1.0:A.Foo)

but I think a better plan is to update cvtName in hsSyn/Convert.hs to validate modules in flavour. (But maybe we want to update the error message here anyway.)

comment:9 Changed 5 years ago by ezyang

OK, fixing this requires a bit of refactoring, but it's not clear which one is best:

  1. One possibility is to fix the code in Language.Haskell.TH to check if a module is valid when it is being created. Unfortunately, this means Module has to be created in the Q monad, and currently it is not.
  1. Another possibility is to check when we are converting the modules, in cvtName. Unfortunately, currently the CvtM monad is a simple error monad, and does not live in TcM, so I can't actually load interface files during the conversion. So doing this conversion would mean CvtM turns into yet another TcRnM alias, and I'm less than keen to monadify code just for this one use case.
  1. Finally, we can add a final "lint" pass on the generated code which, among other things, makes sure the error messages make sense. Since this is done at the splice site, we still have the location information of the splice available.
  1. Augment generated TC splices with splice location, so if we run into an error in spliced code, we properly report where the splice was generated from. Maybe we should just do this anyway?

comment:10 Changed 5 years ago by simonpj

Te basic problem here, which also happened in #, is that "haskell-src-exts-1.16.0.1" is not the key of any package; it's the name/version of the package. Reminder

  • The name/version of a package is something like haskell-src-exts-1.16.0.1. It represents the source code of a particular released package.
  • The key of a package is something like haske_7Ftlz85Zj6I3uisdzq1Sbd; it represents a compiled instance of the package.

Global names (built with NameG) contain package keys.

Edward Y and I talked. Here's our proposal.

  1. Add a new function
    reifyPackage :: String   -- Package name
                 -> String   -- Version
                 -> Q [Package]
    
    which, given a package name/version returns all the installed packages with that name and version.

The auxiliary types are

data Package = Pkg PkgKey        -- Abstract; may grow more fields
newtype PkgKey = PkgKey String   -- Abstract; 

packageKey :: Package -> PkgKey  -- Accessor
packageKey (Pkg p) = p

mkPackageKey :: String -> PkgKey
mkPackageKey = PkgKey   -- Use with caution; these strings are not easy to come up with
                        -- eg "haske_7Ftlz85Zj6I3uisdzq1Sbd"
  1. Improve the error message when splicing code that mentions a bad PkgKey in a NameG, as in comment:8

Notes

  • A TH NameG currently contains a PkgName, defined thus:
    newtype PkgName = PkgName String        -- package name
    
    This is badly misleading; we propose to rename it to PkgKey, defined above. You can get a PkgKey from reifyPackage plus packageKey; or in some other out-of-band-way plus mkPkgKey.
  • reifyPackage returns a list of Packages. There can be more than one if the sane package name/version is installed wrt different dependencies; but this is atypical. At some point we may need to support bigger API for Package, which lets you get its dependencies.

See also #10330.

None of this is for 7.10; it's a proposal for 7.12.

comment:11 Changed 4 years ago by simonpj

Still to push as interim measure: an improvement to the error message. Edward has a patch or this.

comment:12 in reply to:  10 Changed 4 years ago by rwbarton

Replying to simonpj:

  1. Add a new function
    reifyPackage :: String   -- Package name
                 -> String   -- Version
                 -> Q [Package]
    
    which, given a package name/version returns all the installed packages with that name and version.

I'm a little worried that this will encourage the people who previously wrote things like

pkg = "haskell-src-exts-" ++ VERSION_haskell_src_exts

to instead call

[pkg] <- reifyPackage "haskell-src-exts" VERSION_haskell_src_exts

just hoping that the result is a single package version.

I'm not up to speed on the context here, but would it be possible to also provide

thisPackage :: Q Package    -- or maybe just :: Package

that refers to the package currently being built?

(P.S. Sorry if this comment belongs on some other ticket instead!)

Last edited 4 years ago by rwbarton (previous) (diff)

comment:13 Changed 4 years ago by simonpj

Yes, we could certainly provide a way to get the current package. I don't know if that would serve this current use-case, but it's a good idea anyway.

The best way to do that would be to elaborate qReifyModule, which currently returns a ModuleInfo. The latter is just

data ModuleInfo =
  -- | Contains the import list of the module.
  ModuleInfo [Module]

but it should really contain the current Module to:

data ModuleInfo =
  -- | Contains the import list of the module.
  ModuleInfo { mi_this_mod :: Module
             , mi_imports  :: [Module] }}}

Remember that Module is

data Module = Module PkgName ModName 

so you can get the current PkgKey from the Module.

Someone just needs to work carefully through the new API.

comment:15 Changed 4 years ago by Edward Z. Yang <ezyang@…>

In bf4f3e653407d02593a69618fb199b2e2d529c92/ghc:

Give a hint when a TH splice has a bad package key, partially fixes #10279

Previously, if we got a package key in our splice, we'd give
a very unhelpful error message saying we couldn't find
a package 'base-4.7.0.1', despite there being a package with
that source package ID.  Really, we couldn't find a package with
that *key*, so clarify, and also tell the user what the real
package key is.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

comment:17 Changed 4 years ago by ezyang

Milestone: 7.10.2

The partial fix is a simple patch and we should consider putting it in 7.10.2. (re-milestoned)

comment:18 Changed 4 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

Merged to 7.10.2.

comment:19 Changed 4 years ago by thoughtpolice

Owner: ezyang deleted
Resolution: fixed
Status: closednew

Whoops, my bad!

comment:20 Changed 4 years ago by ezyang

Milestone: 7.10.27.12.1

Great, the rest is for 7.12.

comment:21 Changed 4 years ago by goldfire

Component: CompilerTemplate Haskell
Owner: set to ezyang

Edward, I came across this on a sweep of TH tickets. It looks like you should be listed as the owner. Please correct if I'm wrong.

comment:22 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:23 Changed 4 years ago by osa1

I'm wondering if anyone's making any progress on this? I'm still suffering from this bug.

comment:24 Changed 4 years ago by osa1

Cc: osa1 added

I should say that I'm willing to work on this myself, but I have no ideas how TH splices compiled/linked etc. and what's the deal with package ids. If someone can give me some pointers I'd like to give it a try.

comment:25 Changed 4 years ago by osa1

Differential Rev(s): Phab:D1342
Status: newpatch

I started working on this https://phabricator.haskell.org/D1342.

comment:26 Changed 4 years ago by goldfire

Thanks, osa1, for taking this on.

I'm taking the proposal under consideration to be TemplateHaskell/PackageKeyChanges. Under this design, is it still possible to get the package name/version in TH? That might be useful for printing out messages to users, etc.

comment:27 Changed 4 years ago by osa1

Hm, we may have lost the package version part, if it's not included in package id strings. I will check this.

If we lost the version numbers it's not because of this patch, but because of previous changes. This patch is merely for reflecting other changes in TemplateHaskell API and preventing some wrong uses of NameG etc.

If we could provide a way to generate readable strings with version numbers from current package ids, then that would solve the problem. But I'm not sure if version numbers are included in package ids.

comment:28 Changed 4 years ago by goldfire

But for longer package names, the name is truncated in the package key, no? Is there no way to get the full package name anymore?

comment:29 Changed 4 years ago by osa1

If they're truncated, then yes, we lost full names(and maybe also version numbers).

It would be great to have a wiki page about package id design.

comment:30 Changed 4 years ago by osa1

@goldfire, This may be relevant:

-- | A string which uniquely identifies a package.  For wired-in packages,
-- it is just the package name, but for user compiled packages, it is a hash.
-- ToDo: when the key is a hash, we can do more clever things than store
-- the hex representation and hash-cons those strings.
newtype UnitId = PId FastString deriving( Eq, Typeable )

EDIT: There's also this wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/Concepts

Last edited 4 years ago by osa1 (previous) (diff)

comment:31 Changed 4 years ago by osa1

I did some more reading, (2) in this proposal would solve this problem: https://mail.haskell.org/pipermail/libraries/2015-May/025600.html

I believe we can even hide PkgKey type completely, just provide Package to users. Package would then contain package name and version number. In NameG etc. we can use Package instead of PkgKey.

I have no ideas how to implement searchPackage and reifyPackage though, I'll need to read some more code. I thought we're losing name and version information. If that's the case it may not be possible to implement searchPackage as described in the mailing list post.

comment:32 Changed 4 years ago by goldfire

It sounds like we should wait for ezyang's input before delving too much deeper. I see you've already pinged him on IRC. I'm sure he'll be in touch soon.

comment:33 Changed 4 years ago by ezyang

See also #10068 (longer comment coming)

comment:34 Changed 4 years ago by ezyang

Right. So the extended fix suggested by this ticket is a little out of date because of another renaming which is coming soon for GHC 8.0. The main change was "package key" turned into "unit id", and "installed package id" turned into "component id". The main semantic change was that installed package ids don't identify packages anymore; they identify components (usually the library component, but there are other components in a package too); and the main reason we moved away from the "package" nomenclature is laid out in #10622.

So, as far as this ticket is concerned, the easy way to fix it is to just take anywhere you see "Package" and rename it to "Unit" (and "PkgKey" to "UnitId".) There is one little unfortunate thing, which is instead of the "Package" we have "Unit", which might be slightly confusing for users (it's not to be confused with ()) but I can't think of a good alternative.

OK, more on the ticket comments:

Hm, we may have lost the package version part, if it's not included in package id strings. I will check this.

It doesn't matter, the name and the version is reported from the installed package (unit) database. We don't extract it out from the UnitId. The UnitId is opaque! So we're querying against the DATABASE.

If we could provide a way to generate readable strings with version numbers from current package ids, then that would solve the problem. But I'm not sure if version numbers are included in package ids.

With new Cabal, UnitId should be readable by default.

I believe we can even hide PkgKey type completely, just provide Package to users.

That's a possibility, but I think it makes sense to keep them decoupled, so users can synthesize UnitIds (PkgKeys).

comment:35 Changed 4 years ago by osa1

It doesn't matter, the name and the version is reported from the installed package (unit) database. We don't extract it out from the UnitId. The UnitId is opaque! So we're querying against the DATABASE.

Where's that DATABASE, exactly?

comment:36 Changed 4 years ago by goldfire

And how does Cabal enter into the picture?

I'm afraid I'm quite lost here.

comment:37 Changed 4 years ago by osa1

Update: There's nothing to do about this issue. See my comment in Phabricator: https://phabricator.haskell.org/D1342#41793

We just need to clean the package and document things. This could probably be closed.

comment:38 Changed 4 years ago by bgamari

Description: modified (diff)
Resolution: wontfix
Status: patchclosed

Sadly it appears there isn't any good fix here. Instead, we must simply document our way around the problem. To quote osa1 on Phab:D1342,

I realized while thinking about this today that this new API is not a solution to NameG problems caused by new UnitId business, because query functions like reifyPackage are running in Q, so running TH is needed for these functions.

But the whole point of using NameG instead of generating names using quotations was to avoid running TH.

So this API doesn't solve the problem.

We were chatting with @ezyang on IRC and he showed me two things:

  1. Cabal now has a macro CURRENT_PACKAGE_KEY which will keep things working even when NameG is used. (it only helps if we refer to the current package of course, but that's enough for most of the use cases)
  1. With next major release we'll have this: https://git.haskell.org/ghc.git/commitdiff/f16ddcee0c64a92ab911a7841a8cf64e3ac671fd which will solve all the problems caused by NameG and UnitIds.

Long story short, this patch is not needed. What we need is to document things. And also template-haskell package needs some cleaning. For example, we can hide Name stuff. We can move some types that are used by TH generated code to an internal module to prevent users from using them. For example, why mkNameG_v even in Language.Haskell.TH.Syntax? It's not documented, it's not supposed to be used by users. The whole package is a mess.

Oh, also, the package database I'm using in this patch is not the database I should be using. Because such a database doesn't even exist. I actually asked about this here: https://phabricator.haskell.org/D1342#38429 and got this answer: https://phabricator.haskell.org/D1342#38441 which was misleading.

Consequently I'll be closing this as wontfix.

Note: See TracTickets for help on using tickets.