If code in a nested beautify3() call ends up splitting a code line in two, the fact that we now have more code lines to look at doesn't ripple back up the call stack, so the code two stack frames up has the wrong idea about where the nested block ends and where it's supposed to continue processing.
This results in lines at the end of the containing block being duplicated, and the output ending prematurely.
I don't see an easy way to fix this, my current idea would be to wrap the notion of "range of lines to consider" in a class that keeps track of its parent ranges and updates everyone's range if lines are added/removed. Instead of returning two line numbers the nested functions would hand sub-ranges down the call chain. Or maybe keep track of the end of the current range by counting from the end of the line array instead of from the beginning.
Note how the intentionally ugly example above will cause the onegeneric part to be split out of the generic map line down in top->beautifySemicolonBlock->beautifyPortGenericBlock.
The top level didn't get the memo about the added line so it will continue processing at the line that the ); just shifted into so will duplicate the );. Also the loop across all lines will terminate early, so the last line of input is dropped.
Report a bug
If code in a nested beautify3() call ends up splitting a code line in two, the fact that we now have more code lines to look at doesn't ripple back up the call stack, so the code two stack frames up has the wrong idea about where the nested block ends and where it's supposed to continue processing.
This results in lines at the end of the containing block being duplicated, and the output ending prematurely.
I don't see an easy way to fix this, my current idea would be to wrap the notion of "range of lines to consider" in a class that keeps track of its parent ranges and updates everyone's range if lines are added/removed. Instead of returning two line numbers the nested functions would hand sub-ranges down the call chain. Or maybe keep track of the end of the current range by counting from the end of the line array instead of from the beginning.
Input
Note how the intentionally ugly example above will cause the
onegeneric
part to be split out of thegeneric map
line down in top->beautifySemicolonBlock->beautifyPortGenericBlock.Expected Behavior
Actual Behavior
The top level didn't get the memo about the added line so it will continue processing at the line that the
);
just shifted into so will duplicate the);
. Also the loop across all lines will terminate early, so the last line of input is dropped.