The atan case looks fixable, though ugly. There are several other cases where numeric-contagion is assumed to return a numeric-type, not a union type, though it explicitly says it can return a union type. I need to understand how and why the code chooses to represent types in certain ways to make progress which will take some time.
The problem was maybe-infer-iteration-var-type which assumes that numeric-contagion always returns a numeric-type and not a union of numeric types. Similar to the atan case. If the comment on numeric-contagion is correct, then fixing this is good. I will need to think through whether we would want to do better than just failing in this case (assuming that in a later pass of the constraint phase the types will be tighter and we will succeed?).
The atan case looks fixable, though ugly. There are several other cases where numeric-contagion is assumed to return a numeric-type, not a union type, though it explicitly says it can return a union type. I need to understand how and why the code chooses to represent types in certain ways to make progress which will take some time.
I added a patch to handle the decf case here https:/ /github. com/ajberkley/ sbcl/commit/ 2bec20099206852 54aad0af1bc3655 1ac6399839
It is triggered also with the simpler:
(let ((x 813.0d0))
(decf x))
The problem was maybe-infer- iteration- var-type which assumes that numeric-contagion always returns a numeric-type and not a union of numeric types. Similar to the atan case. If the comment on numeric-contagion is correct, then fixing this is good. I will need to think through whether we would want to do better than just failing in this case (assuming that in a later pass of the constraint phase the types will be tighter and we will succeed?).