diff options
| author | Michael Sloan <mgsloan@gmail.com> | 2019-03-13 23:04:41 -0700 |
|---|---|---|
| committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2019-05-22 16:37:57 -0400 |
| commit | 21272670581608b96a85cfb942af81ada3cfd450 (patch) | |
| tree | 703a1256e31868e0878706b9b60781add68ed2c0 /docs | |
| parent | 0dc7985663efa1739aafb480759e2e2e7fca2a36 (diff) | |
| download | haskell-21272670581608b96a85cfb942af81ada3cfd450.tar.gz | |
Have GHCi use object code for UnboxedTuples modules #15454
The idea is to automatically enable -fobject-code for modules that use
UnboxedTuples, along with all the modules they depend on. When looking
into how to solve this, I was pleased to find that there was already
highly similar logic for enabling code generation when -fno-code is
specified but TemplateHaskell is used.
The state before this patch was that if you used unboxed tuples then you
had to enable `-fobject-code` globally rather than on a per module
basis.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/users_guide/8.10.1-notes.rst | 7 | ||||
| -rw-r--r-- | docs/users_guide/ghci.rst | 13 |
2 files changed, 15 insertions, 5 deletions
diff --git a/docs/users_guide/8.10.1-notes.rst b/docs/users_guide/8.10.1-notes.rst index 3086bf411b..ca34106eb4 100644 --- a/docs/users_guide/8.10.1-notes.rst +++ b/docs/users_guide/8.10.1-notes.rst @@ -71,6 +71,13 @@ Compiler process, as long as there are no native dependencies that rely on global state. +- When loading modules that use :extension:`UnboxedTuples` into GHCi, + it will now automatically enable `-fobject-code` for these modules + and all modules they depend on. Before this change, attempting to + load these modules into the interpreter would just fail, and the + only convenient workaround was to enable `-fobject-code` for all + modules. + Runtime system ~~~~~~~~~~~~~~ diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst index d320419f3d..3df5510d74 100644 --- a/docs/users_guide/ghci.rst +++ b/docs/users_guide/ghci.rst @@ -3360,11 +3360,14 @@ The interpreter can't load modules with foreign export declarations! need to go fast, rather than interpreting them with optimisation turned on. -Unboxed tuples don't work with GHCi - That's right. You can always compile a module that uses unboxed - tuples and load it into GHCi, however. (Incidentally the previous - point, namely that :ghc-flag:`-O` is incompatible with GHCi, is because the - bytecode compiler can't deal with unboxed tuples). +Modules using unboxed tuples will automatically enable `-fobject-code` + The interpreter doesn't support unboxed tuples, so GHCi will + automatically compile these modules, and all modules they depend + on, to object code instead of bytecode. + + Incidentally, the previous point, that :ghc-flag:`-O` is + incompatible with GHCi, is because the bytecode compiler can't + deal with unboxed tuples. Concurrent threads don't carry on running when GHCi is waiting for input. This should work, as long as your GHCi was built with the |