Monkey C compiler: Undefined symbol detection is inconsistent

The undefined symbol detection in the Monkey C is compiler is great and a very welcome feature. However, I have noticed that some missing symbols are detected while others are not. I realize that some omissions may be purposeful, to avoid breaking certain types of existing code, but perhaps in those cases the compiler could emit a warning instead of an error?

Environment: CIQ SDK 3.0.7

In the following code, assume that A is an undefined symbol.

function initialize() {
        SimpleDataField.initialize();

        var x = new A(); // produces compile error as expected
        A(); // compiles but crashes at run time
        A = null; // compiles but crashes at run time
        // ...
    }

Marianne.ConnectIQ over 6 years ago

Hi FlowState , I tested the sample code that you provided - all three lines of code resulted in a compiler error for me using the 3.0.7 SDK. Is it possible that you were using an older SDK? Could you possibly provide the code you are testing with and I can test that directly?

FlowState over 6 years ago

Marianne.ConnectIQ Thanks for following up. I am using the latest SDK, 3.0.7.

Sorry, I stupidly edited my test case to make it look better, by changing lowercase "a" to uppercase "A". Turns out that has something to do with it. Here's an updated test case, including an example where it failed for me in my real app (and caused a crash in real life).

Uncomment a test case to see the noted behaviour. Assume that "A", "a", "x" and "power" are all undefined.

var obj;        

//obj = new A(); // Compiler error: Undefined symbol "A" detected.
//A();           // Compiler error: Undefined symbol "A" detected.
//A = null;      // Compiler error: Undefined symbol "A" detected.

//obj = new a(); // Compiler error: Invalid symbol "a" used in the context of a new object instantiation. No class exists with the given symbol name.
//a();           // Compiler error: Invalid symbol "a" used in the context of a function invocation. No function exists with the given symbol name.
//a = null;      // Runtime error: Could not find symbol a. Symbol Not Found Error

//obj = new x(); // Runtime error: Could not find symbol x. Symbol Not Found Error
//x();           // Compiler error: Invalid symbol "x" used in the context of a function invocation. No function exists with the given symbol name.
//x = null;      // Runtime error: Could not find symbol x. Symbol Not Found Error

//obj = new power(); // Runtime error: Could not find symbol power. Symbol Not Found Error
//power();           // Compiler error: Invalid symbol "power" used in the context of a function invocation. No function exists with the given symbol name.
//power = null;      // Runtime error: Could not find symbol power. Symbol Not Found Error

The last case of "power = null" is a real crash that a user saw in my real app in the store, due to an undefined symbol. (Typo/copy-paste error.)

Marianne.ConnectIQ over 6 years ago

FlowState, ahhh okay those scenarios make more sense.

Unfortunately, the symbol checking compiler feature checks if a symbol has ever been defined as opposed to checking if a symbol was defined within the current scope. The symbols you are using, "a" / "x" / "power", are actually symbols within the Toybox API (see api.db found in the SDK's bin directory for a full list of API symbols). I believe this is the reason you are able to fool our symbol checker.

FlowState over 6 years ago

Marianne.ConnectIQ right I forgot that symbol definitions have global scope. While I get why it works that way (and it's pretty convenient), I guess this is the downside....

Thanks!

I will point out that although symbol definitions (the unique names and internal numbers) may have global scope, symbols themselves (the actual variable, const, function or class) obviously do have scope from which they can be referenced at runtime. It would be nice if the compiler knew about this too.