<lkcl>
it's not actually a bug, it's a matter of expectations.
<lkcl>
what you probably are expecting is that because val_out is part of the class Test(), that it should be the only signal out
<lkcl>
possibly
<lkcl>
nmigen doesn't quite work that way: the fact that the Signal exists (or not) has nothing to do with whether it's part of a class (or not), all nmigen actually cares about is, "has it been added to a domain"
<lkcl>
in this case, you added it to a combinatorial domain.
<lkcl>
however... val_out is assigned *to* something.
<lkcl>
therefore, nmigen goes, automatically, "oh, there's now two signals".
<lkcl>
the fact that you didn't put int_sig as self.int_sig is *completely* irrelevant
<lkcl>
what behaviour are you expecting, if int_sig was or was not added to class Test?
<lkcl>
are you expecting int_sig to be ignored?
<lkcl>
if so, what value should be assigned to val_out?
<lkcl>
should it be left completely non-deterministically set to a random or undefined value?
<lkcl>
no, of course not
<lkcl>
so the contract is: if you did not *explicitly* say which ports you wanted, then nmigen *automatically works them out for you*.
<lkcl>
and, because you forgot to add an argument to the verilog.convert function explicitly listing which ports you wanted, nmigen did a complete tree-walk for you and, on finding a list of assignments, back-calculated which ones were inputs and which were outputs.