Opened 15 months ago

Last modified 13 months ago

#7635 new feature request

SafeHaskell implying other options

Reported by: shachaf Owned by:
Priority: normal Milestone: 7.8.3
Component: Compiler Version: 7.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC accepts invalid program Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.)

Change History (2)

comment:1 Changed 15 months ago 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!)

comment:2 Changed 13 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
Note: See TracTickets for help on using tickets.