Skip to content

Remove StgLint type checks

Copying from the mailing list thread:

https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html

I've been looking into some StgLint-related tickets:

  • #13994 (closed): Found a StgLint problem and fixed, there's another problem

waiting to be fixed. Both related with the fact that after

unarisation we lose even more typing information and type

checks needs to be relaxed.

  • #14116 (closed): StgLint failed to look through newtypes, and because coercions

are removed at that point it failed to type check. Solution

was to relax type checks.

  • #5345 (closed): Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes:

        > Fundamentally STG Lint is impossible, because unsafeCoerce#
    > can randomise all the types.

    > This patch does a bit of fiddle faddling in StgLint which
    > makes it a bit better, but it's a losing battle.

  • #14117 (closed): Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate.

  • #14118 (closed): Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that.

  • #14120 (closed): Again type checking errors. Commit for #14116 (closed) also fixes this. The commits compares typePrimReps of types instead of comparing actual types (even this is not enough, see #13994 (closed)).

All this of course took time to debug.

In addition, the new StgCSE pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in Note \[Case 2: CSEing case binders\]\.

There's also this comment in StgLint.hs

WARNING:

~~~~~~~~

This module has suffered bit-rot; it is likely to yield lint errors

for Stg code that is currently perfectly acceptable for code

generation. Solution: don't use it! (KSW 2000-05).

It seems like it hasn't been used since 2000.

All this suggests that

  • Checks related to types are impossible in StgLint. (see e.g. commit

messages in #5345 (closed), #1420, transformations done by unariser and StgCSE)

  • It's not enabled since 2000, which I think means that it's not

needed.

This makes me question whether it's worth maintaining. Maybe we should just remove it.

If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are:

  • After unarise there should be no unboxed tuple and sum binders.

unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this.

  • Variables should be defined before use. I again don't know if this

should be checked, could this be useful for StgCSE?

So I think we should do one of these:

  1. Remove StgLint.
  2. Rewrite it to only check these two and nothing else, enable it in

validate (and in other build flavours that enable CoreLint).

What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it).

Simon suggested creating a ticket and keeping StgLint. This is the tracking ticket.

Trac metadata
Trac field Value
Version
Type Task
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information