Absent unlifted bindings
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 (closed)
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 haveno 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
hasEq
andOrd
-- but I'm not sure why. Try removingthem and seeing what happens! (Generally I think it'd be better to
define
eqLit
andcmpLit
and cal them, rather than use==
and>
;so much easier to grep for!
And in fact, we do have
eqType
andcmpType
. -
Do we need to spit out a
RubbishLit
in theBinary
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.