Stable-types build error moving to 0.9.3 and later versions of the SDK

Developers
1

I am getting the following error when upgrading a project to SDK 0.9.3 and later versions:

Stderr:
stable-types:4.5-4.9: syntax error [M0001], unexpected token ‘type’, expected one of token or sequence:
}
seplist(<typ_field>,) }

Any idea what the issue is here?

3 Likes
2

Note that the build works with SDK 0.9.2 and earlier versions

1 Like
3

From the error message I would guess you’re writing Motoko. Guessing further form that is that a Motoko compiler upgrade changed acceptable syntax. Would you mind sharing the relevant section of the code?

4

Thanks for replying Severin - we don’t know what code is throwing the error, the output above is all we have. We have narrowed it down to one canister but not what code causes the issue.

5

Since the error happens when moving from 0.9.2 to 0.9.3, I had a look at the dfx changelog. There, it says “Updated Motoko from 0.6.21 to 0.6.25.”. Maybe the Motoko changelog for those versions is helpful to narrow it down?

2 Likes
6

+1

That log provides some helpful clues, especially since we don’t have the source code yet in the thread.

I wonder if one of the recent fixes exposed a latent issue in the stable variable definitions of the code? It could be that it should not have parsed before, but only did because of that now-fixed issue being unfixed earlier.

@paulk if you share that line of the code, maybe we can help spot the relevant remedy.

7 
-- Parsing stable-types:
.../Projects/modclub/src/modclub/service/poh/poh.mo:1583.25-1583.37: warning [M0154], field append is deprecated:
Array.append has critical performance flaws; use a Buffer, and Buffer.append, instead.
.../Projects/modclub/src/modclub/service/poh/poh.mo:1590.32-1590.44: warning [M0154], field append is deprecated:
Array.append has critical performance flaws; use a Buffer, and Buffer.append, instead.
.../Projects/modclub/src/modclub/service/poh/poh.mo:1595.20-1595.32: warning [M0154], field append is deprecated:
Array.append has critical performance flaws; use a Buffer, and Buffer.append, instead.
stable-types:8.5-8.9: syntax error [M0001], unexpected token 'type', expected one of token or <phrase> sequence:
  }
  seplist(<typ_field>,<semicolon>) }

We are having the same issue when upgrading from 0.9.2 to 0.11.2 .

I attempted to build without the “stable-type” command but still got the same error:

"../.cache/dfinity/versions/0.11.2/moc" "../Projects/modclub/src/modclub/main.mo" "-o" "../Projects/modclub/.dfx/local/canisters/modclub/modclub.wasm" "-c" "--debug" "--idl" "-v" "--public-metadata" "candid:service" "--actor-idl" "../Projects/modclub/.dfx/local/canisters/idl/" "--actor-alias" "modclub" "rrkah-fqaaa-aaaaa-aaaaq-cai" "--package" "array" ".vessel/array/v0.2.0/src" "--package" "base" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src" "--package" "crypto" ".vessel/crypto/v0.2.0/src" "--package" "encoding" ".vessel/encoding/v0.3.2/src" "--package" "io" ".vessel/io/v0.3.1/src" "--package" "matchers" ".vessel/matchers/v1.2.0/src" "--package" "rand" ".vessel/rand/v0.2.2/src" "--package" "sequence" ".vessel/sequence/v0.1.1/src" "--package" "uuid" ".vessel/uuid/v0.2.0/src"

cc / @claudio @chenyan

8

Feel likes you are missing a semicolon somewhere. If you can share the code around the error lines, it can help us to pinpoint the problem.

1 Like
9

How would I find the code for those error lines? This error doesn’t seem to specify a file that’s in our repo.

10

The file is internally generated by moc from the stable variable declarations in the code and embedded in a custom section of the wasm.

Because earlier, buggy versions of moc sometimes produced ill-formed stable-type files, we added a check that verifies the generated file is valid by parsing and verifying it to detect bugs early.

I think that check might be failing, and has detected a bug.

If you can share the source code, or some cut down version of it including just the stable variables, then we might be able to pinpoint the issue.

3 Likes
11

Another, perhaps easier, helpful thing to share might be the .most file produced by the working compiler (dfx 0.9.2, moc 0.6.21?) with option --stable-types.

12

Here is content of the .most file using dfx 0.9.2:

type Bucket/2 = Bucket/1;
type DataCanisterId = Principal;
type List<T> = ?(T, List<T>);
type UpgradeData/1 = UpgradeData;
actor {
  stable var _canistergeekMonitorUD : ?UpgradeData/1;
  stable var admins : ?(Text, List<Text>);
  stable var cgusers : ?(Text, List<Text>);
  stable var storageStateStable :
    {
      admins : [Text];
      contentIdToCanisterId : [(Text, DataCanisterId)];
      dataCanisters : [(DataCanisterId, Bucket/2)];
      retiredDataCanisterId : [(Text, Text)]
    }
};
1 Like
13

@claudio Sent you a github invite to our codebase

1 Like
14

Sorry for the delay. I’m on vacation. Got the invite and will try to investigate by mid week

1 Like
15

This .most file is bad. type Bucket/2 = Bucket/1. / cannot be a valid variable character. I think we have fixed this, but the file produced by an earlier compiler still exists. Can you override the error? dfx usually asks if you want to continue deploy, you can just say “yes”.

16

I see, I’ve tried to generate a new .most file by commenting out the canister, but found it still throws the error upon reinstall and doesn’t offer a continue prompt, just Stderr.

17

Right, the bad .most file was in the deployed Wasm module. If dfx doesn’t provide a continue prompt, that’s a bug I need to fix.

1 Like
18

Interesting, well if you need more detailed info to be sure, I’ll be happy to provide.

1 Like
19

Fixed here: fix: compatibility check error should not block canister install by chenyan-dfinity · Pull Request #2561 · dfinity/sdk · GitHub. Should be available in the next dfx release. Or you can build dfx locally if you are eager to try.

2 Likes
20

I’ve pushed a PR that works around the bug by making all the public type components of actor class Buckets.mo private. It now builds for me.

2 Likes