[GHC] #10052: Panic (something to do with floatExpr?)

[GHC]

#10052: Panic (something to do with floatExpr?)
-------------------------------------+-------------------------------------
        Reporter:  edsko             |                   Owner:  simonmar
            Type:  bug               |                  Status:  merge
        Priority:  high              |               Milestone:  7.10.2
       Component:  Compiler          |                 Version:  7.10.1-rc2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  GHCi crash        |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:  Phab:D727
-------------------------------------+-------------------------------------

Comment (by Austin Seipp <austin@…>):

 In [changeset:"091944e3aec736b440a9c1204f152004e382c967/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="091944e3aec736b440a9c1204f152004e382c967"
 compiler: make sure we reject -O + HscInterpreted

 When using GHCi, we explicitly reject optimization, because the
 compilers optimization passes can introduce unboxed tuples, which the
 interpreter is not able to handle. But this goes the other way too: using
 GHCi on optimized code may cause the optimizer to float out breakpoints
 that the interpreter introduces. This manifests itself in weird ways,
 particularly if you as an API client use custom DynFlags to introduce
 optimization in combination with HscInterpreted.

 It turns out we weren't checking for consistent DynFlag settings when
 doing `setSessionDynFlags`, as #10052 showed. While the main driver
 handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
 elsewhere.

 This does a little refactoring to split out some of the common code, and
 immunizes the various `DynFlags` utilities in the `GHC` module from this
 particular bug. We should probably be checking other general invariants
 too.

 This fixes #10052, and adds some notes about the behavior in `GHC` and
 `FloatOut`

 As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
 didn't exist (somehow).

 Signed-off-by: Austin Seipp <austin at well-typed.com>

 Reviewed By: edsko

 Differential Revision: https://phabricator.haskell.org/D727

 GHC Trac Issues: #10052
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler