Require imports to be specified without file extension

[kritzcreek]

Fixes #1127

The one subtle change in here is that previously import M "path" and import M "path/" would resolve to import M "path/lib.mo" whereas now it's required to import M "path/", because otherwise it'll try to resolve path.mo

[kritzcreek]

Still need to fix the language server to properly handle these paths

[nomeata]

The one subtle change in here is that previously import M "path" and import M "path/" would resolve to import M "path/lib.mo" whereas now it's required to import M "path/", because otherwise it'll try to resolve path.mo

Hmm, that defeats a bit the purpose of having a nice-looking import M "mo:pkg".

I think we should do one of these:

1. Always first look for foo.mo and then lib/foo.mo
2. Always first look for foo/lib.mo and then foo.mo
3. Look for both and complain if both are avabilable
   4 drop that feature alltogether

If we expect that imports will have some guessing around them anyways eventually (e.g. multiple search paths, or “use .wasm if there, else try .mo”), then 1, 2, or 3 are naturally. Else maybe 4.

@rossberg, opinions?

[rossberg]

I'm fine with either of the options you list, though for simplicity, would probably pick 1/2 over 3. Regarding which one path takes precedent, what do other systems do?

[nomeata]

According to https://stackoverflow.com/a/4092446/946226 python (which I kinda took as inspiration here) does 2; directory before file.

[chenyan-dfinity]

If we have both foo.did and foo.mo, which one takes precedence? I think it's .did, just like .mli.
This is another reason that I think --print-deps should output the resolved file path. We don't want re-implement the resolve logic in dfx.

[nomeata]

That's a good point for returning the full path. Otoh, the point of printing the dependencies is that the build tool (dfx) can possibly generate the missing files. That seems like an unresolvable dilemma.

Maybe we need two modes?

Or print both import URL and (if present) file it resolves to?

[kritzcreek]

I've run into problems with breaking the IDE's file resolution here, so I'm working on unifying that with pipeline first and then I'll get back to this PR.

[chenyan-dfinity]

That's a good point for returning the full path. Otoh, the point of printing the dependencies is that the build tool (dfx) can possibly generate the missing files. That seems like an unresolvable dilemma.

Maybe we need two modes?

Or print both import URL and (if present) file it resolves to?

If we can resolve the file, we don't need dfx to generate any files for us. I think we can output the full path if moc can resolve the imports. The unresolved ones become the obligation of dfx. Opened #1148

[dfinity-ci]

In terms of gas, no changes are observed in 1 tests.
In terms of size, no changes are observed in 1 tests.

[kritzcreek]

Allright, tests seem to be passing again and the IDE now uses the same file resolution as the pipeline. I've implemented the "file exists" based resolution for directory paths, the easiest way to tell if this is what you'd imagined is probably to look at the resolve_import_test.ml unit tests.

PTAL

[ggreif]

Edit: The error that you provide is nicely self-explanatory. I'll shut up.

What about out-of tree code (at externals?)

Can we provide a warning when .mo is present, but ignore it, and look up the import as-if it didn't have an extension?