Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It doesn't understand that the type in canister is the same #4625

Open
vporton opened this issue Jul 22, 2024 · 4 comments
Open

It doesn't understand that the type in canister is the same #4625

vporton opened this issue Jul 22, 2024 · 4 comments

Comments

@vporton
Copy link

vporton commented Jul 22, 2024

The bug is triggered by https://github.com/vporton/bug-canister-type (84b7e50):

$ dfx deploy 
...
/home/porton/Projects/bug/mytest/src/mytest_backend/main.mo:9.14-9.18: type error [M0096], expression of type
  actor {type X = Null; f : shared X__1 -> async ()}
cannot produce expected type
  actor {f : shared X -> async ()}

f has the same type in both and should compile without an error.

For completeness, here is the code:

lib.mo:

module {
    public type X = ();
}

call.mo:

import lib "lib";

actor {
    public shared func f(x: lib.X): async () {
        ();
    };
}

main.mo:

import lib "lib";
import call "canister:call";

actor {
  type T = actor {
    f(x: lib.X): async ();
  };

  let z: T = call;
};

dfx.json:

{
  "canisters": {
    "mytest_backend": {
      "main": "src/mytest_backend/main.mo",
      "type": "motoko",
      "dependencies": ["call"]
    },
    "call": {
      "main": "src/mytest_backend/call.mo",
      "type": "motoko"
    }
  },
  "defaults": {
    "build": {
      "args": "",
      "packtool": ""
    }
  },
  "output_env_file": ".env",
  "version": 1
}
@vporton
Copy link
Author

vporton commented Jul 22, 2024

$ moc --version
Motoko compiler 0.11.2+ (source 3w73qd3r-5pqc5q4p-crdjd8hk-1q2s4w4s)

@ggreif
Copy link
Contributor

ggreif commented Aug 13, 2024

I can reproduce the error. If I have

module {
    public type X = Int;
}

in lib.mo then everything deploys just fine. My hunch is that the Candid conversion of () to Null is the problem. I also tried type X = Null and it is fine too.

@ggreif
Copy link
Contributor

ggreif commented Aug 15, 2024

Please see the comments in the above repro. The gist of the problem is that you define a shared unary function (that has nullary result), and the Candid type mapping is not bijective. I.e. it maps the unary (unit) argument to a unary null Candid type. The reverse mapping from Candid to Motoko then makes the choice to map null to Null. While the two type systems are sufficiently similar for most purposes, here the round-tripping fails unfortunately. Are you really dependent on type X = (), or is this just a sketch of a problem you encounter in the wild?

@vporton
Copy link
Author

vporton commented Aug 15, 2024

Are you really dependent on type X = (), or is this just a sketch of a problem you encounter in the wild?

I don't remember the exact location of the problem where I met it. So, I can't answer your question. Right now the repository from which, if I remember correctly, I got the bug compiles well. But that may be another repository. Sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants