search

dfinity / motoko-base

The Motoko base library
Apache License 2.0
483 stars 98 forks source link

Text.mo:83 type error [M0072], field textCompare does not exist in type #392

Open gabrielnic opened 2 years ago

gabrielnic commented 2 years ago

Hi, since we upgraded to dfx 0.10.1 we're getting this error on build. Stderr: .vessel/base/master/src/Text.mo:83.13-83.17: type error [M0072], field textCompare does not exist in type which points to: let c = Prim.textCompare(t1, t2);

I double checked and vessel is importing the up to date master so that's not the issue.

Also the moc version is 0.6.28 as expected with 0.10.1

/home/gabriel/.cache/dfinity/versions/0.10.1/moc --version Motoko compiler 0.6.28 (source qlnihjin-vcybaf3y-7m8chc90-nfhll89r)

It's weird cause someone else was getting this and I wasn't so I installed a fresh new env of ubuntu and installed everything from 0 and I'm getting this.

ggreif commented 2 years ago

This looks like a glitch in the dfx release process. The included 0.6.28 is too old, since https://github.com/dfinity/motoko/releases/tag/0.6.29 is the moc that contains the improved primitive. EDIT: Or to put it the other way 'round: the imported base library is too new for the moc pinned.

Maybe motoko-base from ToT has been imported, but not the corresponding moc.

Can you just revert Text.mo to a slightly older version?

The good news is that moc 0.6.29 is already in the pipeline for the inclusion into the upcoming dfx.

gabrielnic commented 2 years ago

According to this https://internetcomputer.org/docs/current/developer-docs/updates/release-notes/ 0.6.28 was the expected one . Updated Motoko from 0.6.26 to 0.6.28.

ggreif commented 2 years ago

Right, but they may have pulled in a too new base library.

gabrielnic commented 2 years ago

Right, will try to revert to an older commit then. Thanks

ggreif commented 2 years ago

Sorry for the inconvenience, we'll work on a foolproof mechanism to avoid such a situation in the future.

ericswanson-dfinity commented 2 years ago

dfx 0.10.1 included these three tarballs (see https://github.com/dfinity/sdk/blob/0.10.1/nix/sources.json)

And this is what's in Text.mo around line 83:

/// Returns the order of `t1` and `t1`.
  public func compare(t1 : Text, t2 : Text) : { #less; #equal; #greater } {
    if (t1 < t2) { #less }
    else if (t1 == t2) { #equal }
    else { #greater }
  };

There's no mention of textCompare.

$ dfx cache show
/Users/ericswanson/.cache/dfinity/versions/0.10.1
$ grep -i textCompare /Users/ericswanson/.cache/dfinity/versions/0.10.1/base/Text.mo

I'd start by comparing .vessel/base/master/src/Text.mo with the contents of the above tarball, which should match the contents of $(dfx cache show)/base/Text.mo

gabrielnic commented 2 years ago

Unless I'm missing something, on the latest master I can see compare is still using Prim.

https://github.com/dfinity/motoko-base/blob/9922e9429c689a59c1e02923235ffae21cd22135/src/Text.mo#L83

Vessel is pointing to the latest master which is accurate.

crusso commented 2 years ago

There has been an iterim release of moc 0.6.29. The master version of motoko-base is, I expect, in sync with that, but no longer appropriate for 0.6.28.

Did you configure vessel to use the latest master? It should probably point to motoko-base revision

d5e08966bf8fc117e29b2127b71567b3fc8cd19a

(in order to pull in a base library compatible with moc 0.6.28)

crusso commented 2 years ago

I'm not a regular vessel user, but perhaps this helps: https://github.com/dfinity/vessel#how-do-i-depend-on-a-git-branch-of-a-package

gabrielnic commented 2 years ago

There has been an iterim release of moc 0.6.29. The master version of motoko-base is, I expect, in sync with that, but no longer appropriate for 0.6.28.

Did you configure vessel to use the latest master? It should probably point to motoko-base revision

d5e0896

(in order to pull in a base library compatible with moc 0.6.28)

Yes, vessel is using the latest master. Using an old commit hash (you can use a commit hash in vessel as well) fixed our issue but wondering if there's a better way in order to avoid this. Is the branch next-moc always used for the next moc update?

ggreif commented 2 years ago

next-moc gets merged into master as soon as a released moc is available, and this declares to the CI that a (potentially) increased feature set can be regression-tested.

It is probably safe to pin the commit in the vessel config, but I have no intuition when (and if) it gets bumped or you have to do it yourself.

iamcrisb commented 2 years ago

Using latest versions of vessel v0.6.4 and dfx v.0.10.1 while pointing to version = "moc-0.6.29" and I am facing the exact same error. What should I do to make it work?

ggreif commented 2 years ago

Using latest versions of vessel v0.6.4 and dfx v.0.10.1 while pointing to version = "moc-0.6.29" and I am facing the exact same error. What should I do to make it work?

I have pushed a branch master-moc-0.6.28, so try using version = "master-moc-0.6.28"