[GHC] #7635: SafeHaskell implying other options

#7635: SafeHaskell implying other options ----------------------------------------+----------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- There have been several type checker bugs -- including #7453 and #7354 -- that have led to type-checker unsafeCoerce/panic/etc., which is a problem under SafeHaskell. In many cases the issue is caught by `-dcore-lint`. I'm not sure how much overhead core-linting has, but it seems like it could be a good idea to turn it on by default at least when SafeHaskell is on. Right now it's listed as a "compiler debugging option", but it seems that common wisdom is that you should use it if you care about security. Should you also use `stg-lint`/`cmm-lint`? Any other options? This should be clearly documented. Relatedly: Earlier today someone was running a Haskell-evaluating IRC bot. It was running with SafeHaskell, but also happened to have GeneralizedNewtypeDeriving turned on, which made it possible to derive `unsafeCoerce`. Should more care be taken that unsafe options are never turned on at the same time as SafeHaskell? (Continued from #7354.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7635 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7635: SafeHaskell implying other options ----------------------------------------+----------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Comment(by ezyang): I approve of this idea generally, but because SafeHaskell can also be used as a "coding style" helper, it probably makes more sense to introduce another flag. For good reason too: for example, we also want to turn on -fno-omit-yields to make sure untrusted user code from getting infinite non-allocating loops. (Actually, it's even tougher than that, because we need to compile all our libraries with -fno-omit-yields too!) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7635#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7635: SafeHaskell implying other options ---------------------------------+------------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC accepts invalid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7635#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC