Acknowledged
3 months ago
CIQQA-3111

bug: compiler throws away module from function call + WatchUi has :showToast should be false

import Toybox.Lang;
import Toybox.Graphics;
import Toybox.WatchUi;

function showToast(msg as String or ResourceId, options as { :icon as BitmapResource or BitmapReference or ResourceId } or Null) as Void {
    if (WatchUi has :showToast) {
        WatchUi.showToast(msg, options);
    }
}

Error: Stack Overflow Error Details: Failed invoking <symbol> Stack:
 - showToast() at Utils.mc:5 0x10000d92
 - showToast() at Utils.mc:7 0x10000db7
...

I know some will tell me I shouldn't use the same function name that already exists, which I might do as a workaround, this still is a huge bug in the compiler.

What's more interesting is that it looks like there's another bug hiding here: vivoactive3 doesn't even have WatchUi.showToast, so the whole block should have been skipped altogether...

SDK 8.1.1, simulator, vivoactive3

flocsy🤠
  • 3 months ago in reply to FlowState

    > isn't this exactly the same as

    Yes, probably. Just in that case I was lucky and it chose the one I meant while here I was unlucky

  • 3 months ago

    Also, I recreated the problem by modifying the Input SDK sample to print the value of "WatchUi has :showToast" to the console and, if true, call WatchUi.showToast()

    But when I create a new device app project from scratch and simply display the value of "WatchUi has :showToast" on the screen, the problem doesn't happen.

  • 3 months ago

    I can recreate both problems on Windows or Mac, for a simulated vivoactive3.

    The incorrect has check resolution bug only happens when optimization is enabled and --disable-api-has-check-removal is specified.

    With -O 1/2/3 and --disable-api-has-check-removal specified, the has check bug occurs

    With -O 1/2/3 and --disable-api-has-check-removal not specified, the has check bug does not occur

    Perhaps surprisingly, for -O 0, the has check bug does not occur. (ofc in this case it makes no difference whether --disable-api-has-check-removal is specified or not)

  • 3 months ago

    > I know some will tell me I shouldn't use the same function name that already exists

    I can't speak for anyone else, but I wouldn't tell you that. A blanket policy like that would be ridiculous for many reasons.

    imo using the same function name as an API call is not really the same as naming an enum after a class that's imported into your namespace, especially given that enums and classes have different naming/case conventions in Monkey C. (Yes, it's too bad that Monkey C doesn't give you finer-grained control over imports.)

    If you were writing Java, would you use String as an enum name, for example? Even if you could?

    > compiler throws away module from function cal:

    I could be wrong, but isn't this exactly the same as:

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-ambiguious-and-exists-in-multiple-imported-modules

    forums.garmin.com/.../bug-incorrect-ambigoious-error-message-even-though-correct-module-is-used