[Git][ghc/ghc][wip/8-8-ghci] 7 commits: Fix #16603 by documenting some important changes in changelogs

[Ben Gamari]

Ben Gamari pushed to branch wip/8-8-ghci at Glasgow Haskell Compiler / GHC


Commits:
334dd6da by Ryan Scott at 2019-05-08T13:31:22Z
Fix #16603 by documenting some important changes in changelogs

This addresses some glaring omissions from
`libraries/base/changelog.md` and
`docs/users_guide/8.8.1-notes.rst`, fixing #16603 in the process.

- - - - -
605869c7 by Vladislav Zavialov at 2019-06-03T21:28:12Z
Fix optSemi type in Parser.y

The definition of 'optSemi' claimed it had type

([Located a],Bool)

Note that its production actually returns ([Located Token],Bool):

  : ';' { ([$1],True) }   -- $1 :: Located Token

Due to an infelicity in the implementation of 'happy -c', it effectively
resulted in 'unsafeCoerce :: Token -> a'.
See https://github.com/simonmar/happy/pull/134

If any consumer of 'optSemi' tried to instantiate 'a' to something not
representationally equal to 'Token', they would experience a segfault.

In addition to that, this definition made it impossible to compile Parser.y
without the -c flag (as it's reliant on this bug to cast 'Token' to 'forall
a. a').

- - - - -
f8d24178 by Michael Sloan at 2019-06-04T03:42:46Z
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.

- - - - -
7258f41b by Michael Sloan at 2019-06-04T03:42:46Z
Add PlainPanic for throwing exceptions without depending on pprint

This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.

The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code.  It's on the order of about 130 modules.  This large set of
dependencies has a few implications:

1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.

2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101

(cherry picked from commit fe9034e9b4820214a8c703bd8a3146ce6eed37b8)

- - - - -
3be42032 by Michael Sloan at 2019-06-04T03:42:46Z
Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)

Also removes a couple unnecessary MagicHash pragmas

(cherry picked from commit 061276ea5d265eb3c23a3698f0a10f6a764ff4b4)

- - - - -
a675f498 by Michael Sloan at 2019-06-04T03:42:47Z
Extract out use of UnboxedTuples from GHCi.Leak

See #13101 + #15454 for motivation.  This change reduces the number of
modules that need to be compiled to object code when loading GHC into
GHCi.

(cherry picked from commit c01d5af31c8feb634fc3dffc84e6e7ece61ba190)

- - - - -
7af05bc4 by Michael Sloan at 2019-06-04T03:42:47Z
Use datatype for unboxed returns when loading ghc into ghci

See #13101 and #15454

(cherry picked from commit 64959e51bf17a9f991cc345476a40515e7b32d81)

- - - - -


30 changed files:

- compiler/basicTypes/UniqSupply.hs
- compiler/codeGen/StgCmmMonad.hs
- compiler/ghc.cabal.in
- compiler/ghci/ByteCodeLink.hs
- compiler/ghci/RtClosureInspect.hs
- compiler/iface/BinFingerprint.hs
- compiler/main/GhcMake.hs
- compiler/main/InteractiveEval.hs
- compiler/nativeGen/AsmCodeGen.hs
- compiler/nativeGen/RegAlloc/Linear/State.hs
- compiler/parser/Parser.y
- compiler/utils/Binary.hs
- compiler/utils/FastString.hs
- compiler/utils/Panic.hs
- + compiler/utils/PlainPanic.hs
- compiler/utils/Pretty.hs
- compiler/utils/StringBuffer.hs
- compiler/utils/Util.hs
- docs/users_guide/8.8.1-notes.rst
- docs/users_guide/ghci.rst
- ghc/GHCi/Leak.hs
- ghc/GHCi/UI/Monad.hs
- + ghc/GHCi/Util.hs
- ghc/ghc-bin.cabal.in
- includes/CodeGen.Platform.hs
- libraries/base/changelog.md
- − testsuite/tests/ghci/prog014/prog014.stderr
- − testsuite/tests/ghci/should_fail/T14608.stderr
- testsuite/tests/ghci/should_fail/all.T
- testsuite/tests/ghci/should_fail/T14608.hs → testsuite/tests/ghci/should_run/T14608.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/aa3346be462d6ac5979d07f8cb8ea3c8a79f0e5c...7af05bc4f6c78df5d84a71e8e5f60235e3ced269

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/aa3346be462d6ac5979d07f8cb8ea3c8a79f0e5c...7af05bc4f6c78df5d84a71e8e5f60235e3ced269
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20190603/8ef121b5/attachment.html>