experiment: implement auto-import for unbound variables that could be libs

[crusso]

Flag --implicit-package auto-imports

• libraries for implicit arguments
• libraries for contextual dots but not libraries for unbound identifiers. This PR auto-imports for unbound identifiers too, make the approach more consistent and eliminating many M0057 warning seen with caffeine inference.

TODO:

• [ ] handle a few more cases (type paths?)
• [ ] testing
• [ ] don't auto-import ambiguous List, pure/List etc.
• [ ] issue a warning? Do we, for the other two cases?

[github-actions[bot]]

Comparing from a9fdecf9479d07c241668332e847cb289a63ef84 to 5bb35c368672cc530ef58479b0b7766168f23b13: The produced WebAssembly code seems to be completely unchanged. In terms of gas, no changes are observed in 5 tests. In terms of size, no changes are observed in 5 tests.

[christoph-dfinity]

With the combination of implicit search, contextual dot search, and now this, wouldn't it be easier to just have the --implicit-package add imports for every library in the package to the type checkers env?

[alexandru-uta]

With the combination of implicit search, contextual dot search, and now this, wouldn't it be easier to just have the --implicit-package add imports for every library in the package to the type checkers env?

That's probably a good idea; can/shall we do just that?

[crusso]

With the combination of implicit search, contextual dot search, and now this, wouldn't it be easier to just have the --implicit-package add imports for every library in the package to the type checkers env?

That's probably a good idea; can/shall we do just that?

i just discussed this with @christoph-dfinity and it wouldn't be quite the same. At the moment, we choose to auto-resolve to an implicit import as a last resort, when no explicit import is available. If we actually import everything then we might introduce artificial ambiguities for implicit arguments and dots that are not apparent in the source.

For example, if we had Time.compare and Int.compare, then they are ambiguous if both imported.

It's not even clear to me whether we need the --implicit-package long term, so perhaps we can stick with this for now and remove the entire option later.