StgLint worth maintaining?

9 Feb 2018

      Hi,

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

- #13994: 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: 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:  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: Related with StgLint not keeping up with recent changes (join
          points), because it's not enabled by default in
          tests/validate.

- #14118: 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: Again type checking errors. Commit for #14116 also fixes this.
          The commits compares `typePrimRep`s of types instead of
          comparing actual types (even this is not enough, see #13994).

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

Thanks,

Ömer

Ömer Sinan Ağacan

Simon Peyton Jones

Ömer Sinan Ağacan

tags

participants (2)