When having variable declarations in a script where that variable might never be assigned to, then an incorrect Using undefined variable: @var runtime error is given if that declaration is inside an autoconcat.
Example code:

string @var;
msg();

Problem:
autoconcat() gets the value of declaration string @var, causing this runtime error.

This is essentially "fixed" when using statements after this commit: bd725d0 . As long as a semi-colon is used, there is no error. Should this be closed?

What does doing it without semicolons yield? If that works, then yes, but the bug may have shifted some.

The result is the same in non-strict mode without semi-colons: using undefined variable. If in strict mode or using semi-colons, there's no issue.

I believe that the problem here is that a variable declaration (without assigned value) has a non-void return value. Making this return void would fix this issue and make more sense in general. Only when a declaration is done with an assigned value, that assigned value should be returned for chain-assignments.

I'm not entirely sure how to fix it, without some fundamental changes to how sconcat works. But this brings up a good point that I've been meaning to address for a while, and I think now is the time to fix it. sconcat is a perfectly valid function for a user to use directly, but when we compile autoconcat into sconcat, we lose the fidelity of knowing that actually this is a user defined function or not. If it's autoconcat generated, then it's fine for us to make various assumptions about the code, if it's user defined, we shouldn't change those assumptions. So I propose we add an __sconcat__ version, which, if autoconcat would use sconcat, it turns it into __sconcat__ instead, which, at execution time, does the same thing as sconcat, but if we need to do further introspection, we can. In this case, we're trying to concat an undefined variable and void, and if that were user defined, of course that's an error, and it's a perfectly good thing to have an error there. But in this case, since it's compiler generated, we should suppress the error, and actually just ignore the output of the variables in general, unless we're running in alias mode, and this is the top sconcat. This also solves the other issue where we have to exit() in cmdline, or else we get the variables output to screen.

We could also start identifying statements then, for instance, if we have __sconcat__(assign(...), msg()) then we can safely say that this isn't meant to be concatenated, because we can mark assign and msg as things that are individually statements, and then we can say that the whole chain isn't an actual sconcat. Though.. maybe that would be more difficult, because what you actually need is to track the return value, which in this case would be void (or nothing) but you need to error out if that's being used which is a hard concept to define.