RCG doesn't handle tags running into tags

Specifically in a new version of h1tcscs, the top level was dropped into a subsystem. A low level library subsystem takes input from a goto. The input immediately goes to another goto. The gotos are not properly removed during code generation.

assigned to @erik.vonreis

This may only happen across subsystem boundaries.

I think it's because the subystem flattening may leave both lines in place that go to the input.

The simple link movement used to bypass goto -> from connections would lead to two branches coming from Goto's source, one going to From's destination, and the other still going to the goto. But the code at this point still assumes there's only one branch coming from any node, so when Goto's source is another From node (from a different jump), that From node ends up with two branches coming from it, breaking the assumption.

Fix is to merge the From's destination branch into the Goto's source branch, then delete From's destination branch from its parent so that it only appears in one spot in the model.

closed

reopened

mentioned in merge request !253 (merged)

mentioned in commit 0880257e

mentioned in commit 2ec7f5c7

closed with merge request !253 (merged)

x2sqz, derived from l1sqz seems to be running into a similar issue that isn't fixed by the latest merge.

reopened

in x2sqz, input 1 of the SQZ subsystem is not connected unless a gain module is inserted between the input and the 'from' tag that outputs to it.

In the connection list, the input is listed as a component (ideally it would not be), but nothing lists the input as an output.

I think this the exact same issue, but at the top level. Top level is handled by its own code and that also ought to be updated.

Note the problem can be re-created in 4.2.0 or 4.2.1, so the change in the merge request did not cause the problem.

I can no longer recreate the problem in 4.2.0, but can in 4.2.1, so the recent merge probably does cause the problem with x2sqz.

Problem is that find_branch, when looking for a src line and when faced with a composite line which is line -> line will return the last line even when asked for the first. Any of line -> line -> line... will always return the second line, which is useless.

the new goto eliminator can create such lines. find_branch wants ```line->branch->[line | branch]...``

I will change goto eliminator to put in branches. I'll also write a new subroutine that gets the start of a composite line with a particular destination no matter what. This will replace calls to find_branch used for such purpose.

I did not add the new subroutine on the principle of minimum change.

mentioned in merge request !256 (merged)

mentioned in commit a95d664e

closed with merge request !256 (merged)

mentioned in issue #58

mentioned in issue #61 (closed)

changed milestone to %4.2.1