feat: suggest conversions between primitive types

[crusso]

This PR exploits bidirectional type checking to suggest missing conversions between inferred and expected types.

When the inferred type of an expression does not match the expected type, and both types are primitive, we search
the package environment for suitable direct conversion functions, identified by a to/from prefix and their function type.

Example messages (expect shorted ones in real world usage):

suggest-conversion-ai.mo:7.3-7.5: type error [M0096], expression of type
  Nat8
cannot produce expected type
  Nat
Maybe try conversion:
  `Nat8.toNat(_)`,
  `Nat8.fromNat8(_)`,
  `Nat8.Outer.Inner.toNat(_)` or
  `Nat8.Outer.Inner.fromNat8(_)`?
suggest-conversion-ai.mo:8.3-8.6: type error [M0096], expression of type
  Nat16
cannot produce expected type
  Nat
Maybe try conversion:
  `Nat16.toNat(_)` after adding `import Nat16 = "mo:conv/Nat16"`,
  `Nat16.fromNat16(_)` after adding `import Nat16 = "mo:conv/Nat16"`,
  `Nat16.Outer.Inner.toNat(_)` after adding `import Nat16 = "mo:conv/Nat16"` or
  `Nat16.Outer.Inner.fromNat16(_)` after adding `import Nat16 = "mo:conv/Nat16"`?

By default, we only typecheck and search explicitly imported libraries.

With --ai-errors enabled, the search considers all available libraries available from any included package, even if not explicitly imported, by including all libraries as an implicit import during library resolution. This also allows moc to suggest conversions that are available, but not imported, by suggesting the appropriate library import.

An unfortunate side-effect of this approach is that an implicitly imported library containing incorrect code will cause compilation to fail, but this shouldn't be problem for well-formed packages. It will also increase compilation times since all package libraries will be type-checked, even if not imported. It should not affect code size, since unimported libraries are not linked for compilation.

As part of the PR, I also disable the emissions of warning and hints arising from package libraries. These are particularly annoying for non-imported libraries, but were always annoying even for imported ones (since packages are typically third-party, there is not much users can do to address any warning).

The work here might also provide better support for future VSCode code completion, since it forces the environment to contain all available libraries with their types, not just the imported ones.

For now, we only search for direct conversions. One could use modified Floyd-Warshall or Dijkstra shortest paths algorithm to find the shorted indirect conversions between any two primitive types, but I haven't tried that.

[github-actions]

Comparing from e220418 to fb24a32:
The produced WebAssembly code seems to be completely unchanged.

[chenyan-dfinity]

How about lossy conversions, e.g., Int -> Nat? A common pattern I see from AI is that they compute a Int number and use that as array index, with if conditions that guarantee that Int is positive.

[crusso]

Member

The suggestion don't distinguish between partial/lossy and total conversions, but won't pick up Int.abs either since it doesn't follow to/from pattern. Probably the right thing to do is to add (to base) trapping Int.toNat/Nat.fromInt and maybe even Int.fromNat and Nat.toInt with a warning that it's redundant due to subtyping.

[chenyan-dfinity]

LGTM