GitLab

Transferred from ticket:9279#comment:159974:

For a long time, the worker/wrapper splitter has given up on absent arguments of certain unlifted types: see Literal.absentLiteralOf and Note [Absent errors] in WwLib. This is very annoying because it means that we get left with functions that take a bunch of arguments they do not use, as in this ticket (#9279).

For lifted types T we build an absent value as a thunk of form

  aBSENT_ERROR_ID @T "Used absent value"

This does two things A. It gives us something, of the right type, to use in place of the value

we aren't passing any more.

B. It gives an extra sanity check: if that value is ever used (a compiler

bug) we'll get a runtime error message.

For unlifted types we don't have thunks, so we can't do this. As you can see in absentLiteralOf, for some types we just make up a silly value: e.g. for Char# we use 'x#'; for Int# we use 0#.

Note, however that

• Substituting a particular value serves purpose (A) but not purpose

  (B). A compiler bug would go undetected. This is sad: e.g. #11126

  is a real bug that was detected by (B). But I see no way out.

• It doesn't work for Array#, MutVar#, TVar# etc because we have

  no available literal values of those types.

So Sebastian is suggesting that we add a new literal value -- call it a rubbish value -- which can work for any (unlifted type), extending Literal something like this

data Literal = ...
  | RubbishLit Type

We need to store the type so we can still do literalType.

Now

• Maybe we could get rid of MachNullAddr in favour of this new literal.

• I think -- but I am not sure -- that this literal should never occur

  in code generation. For example, we should never pass a rubbish value

  to a function. Before then dead-code elimination should have got rid

  of it I'm not 100% certain, but if this was true, it'd be a great

  sanity check.

• Yes, Literal has Eq and Ord -- but I'm not sure why. Try removing

  them and seeing what happens! (Generally I think it'd be better to

  define eqLit and cmpLit and cal them, rather than use == and >;

  so much easier to grep for!

  And in fact, we do have eqType and cmpType.

• Do we need to spit out a RubbishLit in the Binary instance.

  This seems more likely, because perhaps these rubbish values can occur

  in unfoldings, which are serialised as their parse tree. But

  the we can just serialise the Type. It won't happen much.