SG-40810: Error/exception when using Wipes if adding "use app_utils" to wipes.mu

[pbergeron-adsk]

Linked issues

SG-40810

Describe the reason for the change.

Fixing bug in Mu interpreter.

Summarize your change.

When trying to resolve a Mu overload, if the resolving happens in the 2nd stage, an incorrect overload symbol name is used to match possible overloads.

To repro this bug:

Add "use app_utils.mu" to the start of wipes.mu (this triggers the bug)
Launch RV
Load multiple medias
Select Tools>Over.
Select Tools>Wipes.

Error appears in the console.

Contents/PlugIns/Mu/wipes.mu, line 102, char 62: 
Unresolved function call to **"app_utils.&&"**
ERROR: while loading source module Contents/PlugIns/Mu/wipes.mu"
ERROR: attempted call to unresolved function
ERROR: event = pointer--move
ERROR: function = __lambda2031 (void; Event event)
ERROR: Exception Value: exception: "attempted call to unresolved function"

This is because of another one of those probably 15+ years old bug in mu.

Line 102 of wipes.mu reads as follows:

if (i.inside && manipTFormNode != enode.tformNode) ....
It's a super innocent line, why would it not find "&&" ? it's a standard operator, built-in to the language itself!

Now, in app_utils.mu, there is an overload for &&, but that overload has nothing to do with any logic operator, it's for calling two menu state functions instead of one at the same time).

Both sides of the && are bools. (i.inside, and the string comparison) and the interpreter is determining that correctly. There's a hint of what's happening: it can't match
(bool && bool) to the completely unrelated && in app_utils.mu

So, the problem isn't that it's trying to do implicit type conversion of the two bools to incompatible types, it's that it's just simply no longer finding the default && in the global scope.

I traced the problem through to NodeAssembler.cpp (yeah, another one of those super deep bugs in Mu) and I managed to get the following patch. However that patch doesn't belong in wipes.mu.

The problem experienced in wipes.mu happens because:

• adding "use app_utils.mu" to wipes.mu adds a "&&" overload (siiiiiigh) to the list of symbols.

• wipes.mu is only deferred-loaded (not when rv starts or rvui is loaded), when we activate the "Wipes" command in the rvui menu.

• At line 102, "i" is an implicit item from an implicit collection ("infos" declared using "let", not its typename), and the same thing with "enode".

• During the first Mu parsing stage, "&&" is still unresolved because the parser doesn't know what "i" or "enode" is, so it's deferring to the 2nd parsing stage. Unfortunatey, it's pushing the fully qualified name "app_utils.&&" (not "&&" as it should") to be resolved in the 2nd parsing stage. (this is the bug)

• During the second parsing stage, the global-scope && is not found because it doesn't match the fully qualified name, ("app_utils.&&") we pushed in the first stage, and since "app_utils.&&" doesn't understand bools, we get the error.
  Note that the bug does not appear if I update the code with explicit types like the attached pic.

While the root of the problem is in NodeAssembler.cpp, we were also being ridiculous by trying to overload "&&" in app_utils.mu for combining two menu state funcs into one.

To reproduce this bug, you will also need to restore the overloaded && from app_utils.mu , which might already be gone by the time this PR goes through, but the root cause in NodeAssembler.cpp remains and it's the way to reproduce it.

Also, I havent seen it used that over overload actually anywhere. It was recommended that I remove the overload from app_utils.mu because it's a footgun, so I did (in a different PR unrelated to this), and the problem indeed went away.

But the bug is still in NodeAssembler so we should consider fixing it properly. As you can see, there was already half the fix for it already present, in the 2nd portion of the code change.

Describe what you have tested and on which operating system.

macOS.

Add a list of changes, and note any that might need special attention during the review.

If possible, provide screenshots.

[bernie-laberge]

LGTM