[m-rev.] Compiler bug found

[Zoltan Somogyi]

On Mon, 24 Nov 2025 18:39:44 +0100, Volker Wysk <post at volker-wysk.de> wrote:
> I found a compiler bug.

Once again, this is not a compiler bug. Please look at ALL the error messages
the compiler gives you before claiming that a problem is in the compiler,
instead of in your code.

> 
> :- pred umbenennen_1(
>     list(pair(iosupp.path, iosupp.path))::in,  
>     pair(iosupp.path, iosupp.path)::in,        
>     io::di, io::uo
> ) is det.
> 
> umbenennen_1(Symlinks, PfadAlt - PfadNeu, !IO) :-
> 
>     !( iosupp.path_exists_p(no, PfadNeu), Existiert1, !IO ),
>     (
>         Existiert1 = yes,
>         write_string("-1-\n", !IO),             % <-- HERE
>         throw("Zielpfad " ++ quote(unslice_path(PfadNeu)) ++ 
>             " gibt es schon. Kann " ++
>             quote(unslice_path(PfadAltEcht)) ++ " nicht umbenennen.")
>     ;
>         Existiert1 = no
>     ),

At the point of the throw, the value of PfadAltEcht has not been defined yet.
The compiler therefore attempts to move the whole switch to a later position,
and the mode error occurs because there is no later position that works.
And as one of the possible causes of the mode error, the compiler tells you
about PfadAltEcht being free at this program point.

> When the line marked with "<-- HERE" is commented out, all is fine.

That is because moving the switch to a point after the definition of PfadAltEcht
also moves it after some I/O operations. State variable notation inherently imposes
(in fact, it is *designed* to impose) an order on the state updates, and the move
of the switch conflicts with this order. This conflict is what is reported as the mode error.

The compiler reposts multiple possible causes of the error because it cannot read
your mind about which way you may want to resolve the conflict.

Zoltan.