Importing a nonexistent module/type using from syntax does not yield any errors

[radeusgd]

Repro

Run the following code:

from Standard.Base import Something_That_Does_Not_Exist

main = 423

Expected Behaviour

Import resolution should fail and tell me that Something_That_Does_Not_Exist does not exist.

Actual Behaviour

Instead the code runs OK and prints 423 on output.

[radeusgd]

It's even more suspicious if you run the following code:

from Standard.Base import Something_That_Does_Not_Exist

main =
    Something_That_Does_Not_Exist.do_a_thing_for_me 42

It yields:

In module nonexist:
Compiler encountered errors:
nonexist.enso[4:5-4:33]: The name `Something_That_Does_Not_Exist` could not be found.
Aborting due to 1 errors and 0 warnings.
Execution finished with an error: Compilation aborted due to errors.

So yeah, it does report that the module was not found at usage site. But I can see I have an import that did not fail. Now I'm confused - I successfully imported this module, it should be here. If the module name does not have a weird name, I have no clue that it actually didn't exist instead.

Note that if I'd run the import without the from form:

import Standard.Base.Something_That_Does_Not_Exist

main =
    Something_That_Does_Not_Exist.do_a_thing_for_me 42

Then I get:

In module nonexist:
Compiler encountered errors:
nonexist.enso[1:1-1:50]: The module Standard.Base.Something_That_Does_Not_Exist does not exist.
nonexist.enso[4:5-4:33]: The name `Something_That_Does_Not_Exist` could not be found.
Aborting due to 2 errors and 0 warnings.
Execution finished with an error: Compilation aborted due to errors.

So it correctly points out that it was unable to import the module and now I know why it is later not found.

With from I do not know why it is not found, assuming that as I did not get any import resolution errors, the import must have succeeded.

cc: @hubertp you may be interested in this, as you know the imports resolution well

[JaroslavTulach]

cc: @hubertp you may be interested in this, as you know the imports resolution well

Yup. I think @hubertp will need to take a look when not occupied with other pressing stuff.

[hubertp]

Yes, it's been like that forever.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-04-27):

Progress: - Looking into the IRs in import expressions and into ImportResolver.

• Added failing tests. It should be finished by 2023-05-03.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-04-28):

Progress: - Hacking ImportResolver to properly import not only modules, but also types and methods from types.

• Learning the proper Scala way of coding. Big thanks to Hubert for helping out. It should be finished by 2023-05-03.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-02):

Progress: - Doing daily bookclub, reporting some issues.

• Struggling with the CI
• Digging into the issue of transitive imports/exports. It should be finished by 2023-05-03.

[JaroslavTulach]

Shouldn't

from Standard.Base import Something_That_Does_Not_Exist

main = 412

yield a warning? Something Something_That_Does_Not_Exist isn't used? That would be way simpler check than trying to resolve symbols from other modules...

[wdanilo]

If the imported module does not exist, there should be a warning about it (explicitly telling that it does not exist). Warning is better than error, as it is less error-prone - more projects will work. If this happens and the graph still works, for the user it give a way more "stable" feeling than crashing with an error. I know this is not how IDEs work, but Enso is not an IDE and we should be as error-prone as possible.

[enso-bot]

Pavel Marek reports a new 🔴 DELAY for today (2023-05-03):

Summary: There is 8 days delay in implementation of the Importing a nonexistent module/type using from syntax does not yield any errors (#5936) task.
It will cause 8 days delay for the delivery of this weekly plan.

Requires deeper investigation and testing of our import/export system.

Delay Cause: The issue is broader than expected at the beginning.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-03):

Progress: - Investigating why benchmarking job takes 8 hours

• Going to split the benchmarks into "Engine benchmarks" and "Library benchmarks"
• Setting up a daily systemd service to upload the benchmark results.
• Setting up a small testing infrastructure for transitive imports/exports
  • Synthetic edition in a tmp directory It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2023-05-05):

Progress: - Added new compiler step that ensures that symbols from from imports are resolved to types or modules

• It cannot be implemented as a separate compiler pass, neither can it be implemented in ImportResolver, as we need ExportResolver to run before.
• Simple tests already work, but Standard library cannot be compiled. It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-08):

Progress: - Adding some logging to understand better what is going on.

• Adding tests that create a package with arbitrary modules and scans its metadata.
• SymbolsImportResolution is capable of resolving members on types.
• We will probably need to add support for ResolvedMethod as ImportTarget. It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2023-05-09):

Progress: - Adding and fixing more import/export tests It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-10):

Progress: - Import resolver can import all constructors from a type

• Adding more specific error messages. It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2023-05-11):

Progress: - Triaging

• Adding and fixing more tests It should be finished by 2023-05-11.

[enso-bot]

Pavel Marek reports a new 🔴 DELAY for yesterday (2023-05-11):

Summary: There is 7 days delay in implementation of the Importing a nonexistent module/type using from syntax does not yield any errors (#5936) task.
It will cause 7 days delay for the delivery of this weekly plan.

My local tests are already passing. I am done with adding more functionality to the import resolver, but I still need to fix all the other tests and be able to compile the whole std lib. I also expect that the PR review will take some time, as it touches a lot of lines of code.

Delay Cause: The issue grew up in complexity and I need more time to fix it.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-12):

Progress: - Wrote rest of the import/export tests.

• My own ImportExportTest pass.
• Fixing other runtime tests.
• Consultation with Hubert, integrating some early review comments. It should be finished by 2023-05-18.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-15):

Progress: - Triaging session with Pawel

• More triaging
• Investigating the recent performance regression when opening a project It should be finished by 2023-05-18.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2023-05-16):

Progress: - Bumping into ambiguity resolution errors during std lib compilation.

• Big discussion about import/exports resolution algorithm. It should be finished by 2023-05-18.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-17):

Progress: - With Jaroslav, concluded that the current PR got out of hand - we need to simplify and integrate.

• Abandoning the current PR, and starting a new one.
  • Tracked the old one under Import resolver should be capable of resolving also methods and constructors #6729, along with links to the PR
• Created a new compiler pass that is heavily simplified and just checks whether the symbols are resolvable
• The PR is now ready to review, with few tests failing.
• Seems like this is pretty much straightforward to implement, should be done tomorrow. It should be finished by 2023-05-18.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2023-05-18):

Progress: - Another triaging session with Pawel

• Various PR reviews
• Improved the functionality such that all the unresolved symbols are reported
• Only lib guys review required It should be finished by 2023-05-18.

[enso-bot]

Pavel Marek reports a new STANDUP for the provided date (2023-05-04):

Progress: Looking at IRs of stdlib and figuring out the incosistencies in ImportResolver. It should be finished by 2023-05-18.