#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description:

With GHC 8.4.3 (`ghc` below on both Ubuntu 16.04.5 and Ubuntu 18.04.1) and recent GHC (`~/dev/ghc/inplace/bin/ghc-stage2` below on Ubuntu 16.04.5; not `HEAD` but close at `ff29fc84c03c800cfa04c2a00eb8edf6fa5f4183`), I get errors for `a = show 5`.

I run the following commands, showing that `show 5` is usually fine:

{{{ $ ghc -fobject-code -O2 -e 'show 5' "5"

$ ghc -fobject-code -O2 -e 'let a = show 5 in a' "5" }}}

But not with `a = show 5`:

{{{ $ ghc -fobject-code -O2 -e 'a = show 5' <interactive>: Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. }}}

Running with `ghci` gives the same error:

{{{ $ ghci -fobject-code -O2 GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> a = show 5 Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. Prelude> Leaving GHCi. }}}

Both errors stop when optimization is turned off:

{{{ $ ghc -fobject-code -O0 -e 'a = show 5'

$ ghci -fobject-code -O0 GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> a = show 5 Prelude> Leaving GHCi. }}}

New description: With GHC 8.4.3 (on both Ubuntu 16.04.5 and Ubuntu 18.04.1) and recent GHC (not `HEAD` but close at `ff29fc84c03c800cfa04c2a00eb8edf6fa5f4183` on Ubuntu 16.04.5), I get errors for `a = show 5`. I run the following commands, showing that `show 5` is usually fine: {{{ $ ghc -fobject-code -O2 -e 'show 5' "5" $ ghc -fobject-code -O2 -e 'let a = show 5 in a' "5" }}} But not with `a = show 5`: {{{ $ ghc -fobject-code -O2 -e 'a = show 5' <interactive>: Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. }}} Running with `ghci` gives the same error: {{{ $ ghci -fobject-code -O2 GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> a = show 5 Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. Prelude> Leaving GHCi. }}} Both errors stop when optimization is turned off: {{{ $ ghc -fobject-code -O0 -e 'a = show 5' $ ghci -fobject-code -O0 GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> a = show 5 Prelude> Leaving GHCi. }}} -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why doesn't this happen ''all the time'' in GHCi? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: monoidal Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => monoidal Comment: The bug should be in `DynFlags.makeDynFlagsConsistent`. monoidal will submit a patch for this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * owner: monoidal => JulianLeviston Comment: Trying this as my first ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: RolandSenn (added) Comment: I think you're right. This is another example of problems caused by not having the information of whether we're in interpreter or not in the compiler (we only have information derived from the flags but that information can't tell reliably whether we're in interpreter, as in this ticket). @RolandSenn has a good summary of the problem in Phab:D5122 which also links to a few other issues caused by this problem. Perhaps we should do the refactoring to add a field to DynFlags about whether we're in interepreter. If we do this then maybe we should revisit some of the fixed tickets and fix them "properly" by using the new field. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): As you say, `HscInterpreted` means modules are compiled to bytecode and then interpreted. Interpreter can interact with native code and with `-fobject-code` you tell GHCi to compile the loaded modules to native code rather than to bytecode (the default, or `-fbyte-code`). Either way the expressions you type in the GHCi prompt are compiled to bytecode and interpreted, so I think those options are only applied to the loaded modules. We need to avoid optimising those expressions. I think another (simpler) way for this might be to find the top-level function for compiling GHCi expressions to bytecode, and override relevant `DynFlag` fields there so that down the line the desugarer and simplifier do not optimise it. That means no new field to `DynFlags` so think it would be even better. If the top-level function to compile a GHCi expression/statement is also used for other purposes perhaps we can introduce a new top-level function for GHCi only, and override relevant `DynFlags` fields there. How does that sound? Sounds better to me as we don't add more to `DynFlags` (which is already huge). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

As you say, HscInterpreted means modules are compiled to bytecode and

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I've been still looking at this, just to keep this updated. then interpreted. Interpreter can interact with native code and with -fobject-code you tell GHCi to compile the loaded modules to native code rather than to bytecode (the default, or -fbyte-code). The above paragraph confused me. The `-e` and `--interactive` flags setup `HscInterpreted` as the language in `main'` in `Main.hs`. DynFlags can be used to override this target (ie with `-fbytecode` or `-fobjectcode`). It seems like a mistake to be able to override it when it's already set to the `HscInterpreted` target, though I don't really understand if that's actually wanted. Like, in the case that you're using `ghci`, would you ever want to turn on `-fobjectcode` from within the interpreter? What would that mean if you could do that? Would it start compiling to object code and ''then'' execute the compiled code? If you're compiling with `ghc --make` and you also use `-fbytecode` is that something that's intended? I guess I'm trying to figure out if, when `-e` and `--interactive` set the `HscInterpreted` target it actually makes more sense to have that be a mode of the compiler that cannot be adjusted via `DynFlags` rather than the target which '''can''' be adjusted. However, I don't know the intent well enough. I'm not sure it's captured anywhere? The `man` doc for `ghc` seems to be extremely brief on what these particular flags mean, or are intended for. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Oh that's much clearer, thank you. I'll have to dig in more to find out about the split of compilation of loaded modules versus expressions (at GHCi prompt and/or given to `-e` flag) to think about how to separate those two types of code. As far as I can see so far in my explorations, `HscInterpreted` (ie the target) is the marker used to determine whether to compile to bytecode or not. Loading with `-e` or `--interpreted` sets this, and Setting `-fbytecode` sets it, too, and conversely, setting `-fobjectcode` sets it to the standard compile target for the platform (which is near `HscInterpreted`. Thanks for being so helpful and patient. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): To refresh my brain (and so I don't have to re-load this into my brain over and over)... as per above, but with annotation: 1. In `ghc/Main.hs`, the `main` function is the entry point for all of GHC. 1. The line with `(mode, argv3, flagWarnings) <- parseModeFlags argv2` parses the mode flags out. There are two possible cases here: either we have a `Left preStartupMode` or `Right postStartupMode`. The `preStartupMode` case is only for doing things before GHC starts up; things such as outputting the version number, etc (ie not executing code). So, we're only interested in the `Right postStartupMode` variant. 1. Continuing on, we start `GHC` by using `GHC.runGhc` with `mbMinusB`, then pull the flags out with `GHC.getSessionDynFlags`. We then `case` on `postStartupMode` which itself is an `Either` as well... it's similar to above, but here we have some `preLoadMode` values that (I'm assuming) can only be got when `GHC` has started up. Things like showing info, ghc usage, ghci usage and printing the flags. Here, though, we're only interested in the `Right` variant again — the `postLoadMode` value gets pattern matched out and; 1. next this hits the `main'` function as: `main' postLoadMode dflags argv3 flagWarnings`. This function then cases on `postLoadMode`... and the only branches of this we're really interested in is `DoInteractive -> (CompManager, HscInterpreted, LinkInMemory)` and `DoEval _ -> (CompManager, HscInterpreted, LinkInMemory)`... there are five other matches, but they're make, backpack, something called MkDependHS and also AbiHash, then the catchall (ie `_`). Essentially we want to block optimisation on the interactive and eval cases. So, this matches `(mode, lang, link)` to the values `(CompManager, HscInterpreted, linkInMemory)` respectively for both of these cases (interactive and eval). 1. Next we use a series of `let` expressions building up dflags1, dflags2, dflags3, etc. then, at the very end, we have another case stateament inside of an evaluation of `handleSourceError` to handle source code errors... again, the only two cases we care about are `DoInteractive` and `DoEval exprs`, both of which evalute to `ghciUI` expressions. Respectively: `ghciUI hsc_env dflags6 srcs Nothing` and `ghciUI hsc_env dflags6 srcs $ Just $ reverse exprs`. 1. The `ghciUI` function pulls the flags out after initializing the plugins with the `hsc_env` and `dflags0`, then sets this into the session with `GHC.setSessionDynFlags`. We then call the `interactiveUI` function with args thusly: `interactiveUI defaultGhciSettings srcs maybe_expr`. This function comes from the `GHCi.UI` module in `ghc/GHCi/UI.hs`. So, we want to investigate `interactiveUI` in `ghc/GHCi/UI.hs`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler