Acknowledged
CIQQA-3490

Compilator wrongly assuming 'Attempting to perform container access on null.'

Hey,

I'm currently developing a Connect IQ app and I think I found a bug in the MonkeyC compilator. With the following code, the second line in the onStart method would be underlined with the error  'Attempting to perform container access on null.'. Trying to compile would result in the same issue. This is performed from the default widget template app with VSCode, SDK version 8.2.3 and trying to compile for device forerunner 955.

import Toybox.Application;
import Toybox.Lang;
import Toybox.WatchUi;
import Toybox.System;

class testApp extends Application.AppBase {
    public static const RESOLUTION_MAP = {
        1   => [:_4K, :_16R9],
        4   => [:_2K7, :_16R9],
        6   => [:_2K7, :_4R3],
        7   => [:_1440, :_16R9],
        9   => [:_1080, :_16R9],
    };

    function initialize() {
        AppBase.initialize();
    }

    // onStart() is called on application start up
    function onStart(state as Dictionary?) as Void {
        var test = 1;
        var result = RESOLUTION_MAP.get(test)[0];
        System.println(result);
    }

    // onStop() is called when your application is exiting
    function onStop(state as Dictionary?) as Void {
    }

    // Return the initial view of your application here
    function getInitialView() as [Views] or [Views, InputDelegates] {
        return [ new testView() ];
    }

}

function getApp() as testApp {
    return Application.getApp() as testApp;
}
I found a workaround by type checking the container access as followed so that I can compile my code, but I still get a compilation warning for the line within the if statement 'Statement is not reachable'. I checked in a test project, and the statement is actually reachable if the key provided exists in the const Dictionary RESOLUTION_MAP.
var resolution = RESOLUTION_MAP.get(setting);
if (resolution instanceof Symbol) {
    System.println(RESOLUTION_LABELS.get(resolution[0]));
}

Don't hesitate to reach out to me if you need any other information to reproduce the issue !
ad220
Parents
  • I noticed that the compiler tries to be smart here.
    e.g. If I change/add a key with a different value type in a function, then get the same key immediately afterwards in the same function, the compiler will infer the new value type or null.
    While this is nice, since it's actually trying to be smart, why not infer the new value type and not null?
    But of course, if I move the access of key 4 to a different function, the compiler infers the *original* value type.
    While it's obvious why this is happening, maybe it suggests that the compiler should *never* be inferring the original value type for a get of any key for a dictionary?
    It looks like the compiler is:
    - trying to be too smart in some cases: inferring VALUE_TYPE or Null for an arbitrary get() when it should be Object or Null
    - not being smart enough in some cases: inferring VALUE_TYPE or Null for a get() that follows a known put() when it should be VALUE_TYPE. (At least be consistent and infer Object or Null.)
    [4/4]
Comment
  • I noticed that the compiler tries to be smart here.
    e.g. If I change/add a key with a different value type in a function, then get the same key immediately afterwards in the same function, the compiler will infer the new value type or null.
    While this is nice, since it's actually trying to be smart, why not infer the new value type and not null?
    But of course, if I move the access of key 4 to a different function, the compiler infers the *original* value type.
    While it's obvious why this is happening, maybe it suggests that the compiler should *never* be inferring the original value type for a get of any key for a dictionary?
    It looks like the compiler is:
    - trying to be too smart in some cases: inferring VALUE_TYPE or Null for an arbitrary get() when it should be Object or Null
    - not being smart enough in some cases: inferring VALUE_TYPE or Null for a get() that follows a known put() when it should be VALUE_TYPE. (At least be consistent and infer Object or Null.)
    [4/4]
Children
No Data
Copyright © 1996-2025 Garmin Ltd. or its subsidiaries