-fth-dec-file uses qualified names from hidden modules

In cross compilation builds, the current TH situation is a bit of a showstopper. However, much TH code is 'safe' to cross-compile. Before the TH situation is solved, it would be great if GHC could automate as much of the work-around process as possible. -dth-dec-file is a big step on the way to create a non-TH version of the source. However, there are some problems with the generated code. One is that qualified names from hidden modules are used. A instance declaration for Aeson.ToJSON is outputted as follows:

instance Data.Aeson.Types.Class.ToJSON InputDropboxFiles where

Ideally, GHC would be able to combine the splice output with the original file, replacing all $() with the corresponding splice, and even generate correct imports. I personally think this would be a great solution to the TH problem. Most cross-compilation projects could just generate the non-TH version with the host GHC, and the few that depends on architecture specific variables can be edited before cross-compiled

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Fabian: I think I read you have a list of issues to report, hence I'm mentioning the following;

For all bug reports, please attach or copy-paste a small program (as small as possible is best) that demonstrates the bug you found, including the instructions to compile and run it. This saves us time constructing it ourselves, and we can put it in the testsuite later. See wiki:ReportABug#Fulldescription:whatinformationtoprovideinthebodyofyourbugreport. Thanks!

mentioned in issue #10703 (closed)

Replying to [ticket:10701#comment:102968 thomie]:

Fabian: I think I read you have a list of issues to report, hence I'm mentioning the following;

For all bug reports, please attach or copy-paste a small program (as small as possible is best) that demonstrates the bug you found, including the instructions to compile and run it. This saves us time constructing it ourselves, and we can put it in the testsuite later. See wiki:ReportABug#Fulldescription:whatinformationtoprovideinthebodyofyourbugreport. Thanks!

I'll put together a test case tomorrow and add it to the ticket

Attached file Test10702.hs ($1117).

Trac metadata

Trac field	Value
Component	Compiler → Template Haskell

Fabian: did you add the right test here (filename makes it appear it is for a different ticket)?

Replying to [ticket:10701#comment:103103 thomie]:

Fabian: did you add the right test here (filename makes it appear it is for a different ticket)?

Yes it's the right file. I made one for several tickets. I have updated all tickets with a new file without the dependency on aeson, and with ddump-splices output included

However, this one was tricky and I will leave it with the aeson dependency. Someone with greater knowledge about the base packages might fix it

changed milestone to %8.0.1

Milestone renamed

added TemplateHaskell label

added compiler crash label

added Pnormal label