Infer method calls on known types and warn about nonexistent methods

[radeusgd]

Pull Request Description

• Implements Inferring types of method calls on Atoms #9812
• Allows us to propagate type inference through method calls, at least in a basic way.
• Adds a 'lint warning': when calling a method on an object of a known specific (non-Any) type that does not exist on that type, a warning is reported, because such a call would always result in No_Such_Method error at runtime.
  • Any has special behaviour - if x : Any we don't know what x might be, so we allow all methods on it and defer to the runtime to see if they will be valid or not.
  • This check is not proving correctness, but instead it's only triggering for 'provably wrong' situations.
• Includes changes from Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution #11955:
  • removing obsolete AtomTypeInterface,
  • simplifying TypeRepresentation to be a plain data structure,
  • and removing a cycle from IR in BindingsMap in favour of relying on StaticModuleScope.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[radeusgd]

I'm getting weird test failures in ModuleManagementTest, removing the assertion as @Akirathan suggested has changed the error but it is still failing at deserialization in a weird way:

[info] - should allow importing literal-source modules *** FAILED *** (1 second, 195 milliseconds)
[info]   org.graalvm.polyglot.PolyglotException: java.lang.ArrayIndexOutOfBoundsException: Index 158052 out of bounds for length 1
[info]   at org.enso.persistance/org.enso.persist.PerInputImpl$InputCache.getRef(PerInputImpl.java:351)
[info]   at org.enso.persistance/org.enso.persist.PerInputImpl.findReference(PerInputImpl.java:58)
[info]   at org.enso.persistance/org.enso.persist.PerReferencePeristance.readObject(PerReferencePersistance.java:33)
[info]   at org.enso.persistance/org.enso.persist.PerReferencePeristance.readObject(PerReferencePersistance.java:8)
[info]   at org.enso.persistance/org.enso.persist.Persistance.readWith(Persistance.java:162)
[info]   at org.enso.persistance/org.enso.persist.PerInputImpl.readInline(PerInputImpl.java:67)
[info]   at org.enso.runtime/org.enso.interpreter.caches.PersistBindingsMap_Argument.readObject(PersistBindingsMap_Argument.java:14)
[info]   at org.enso.runtime/org.enso.interpreter.caches.PersistBindingsMap_Argument.readObject(PersistBindingsMap_Argument.java:4)
[info]   at org.enso.persistance/org.enso.persist.Persistance.readWith(Persistance.java:162)
[info]   at org.enso.persistance/org.enso.persist.PerInputImpl.readIndirect(PerInputImpl.java:218)
[info]   ...

Interestingly, it seems that my followup PR #11955 that removes the BindingsMap -> Expression cycle from the IR seems to not have these failures.

@JaroslavTulach do you think we can merge both PRs at once (I need to finish the followup but I'm working on that) OR would you like to help me investigating this serialization issue? Seems like there is still some issue in the persistance when cycles are around.

IMO it will be easier to just merge the followup, although we can also try investigating the persistance to make it more robust as such failures probably shouldn't be happening - but I don't think fixing persistance should be the focus of this PR in more extent than necesary.

[radeusgd]

I wanted to keep these PRs separate but it initially (I'm waiting for full CI suite to pass to verify) seems that the followup PR #11955 is fixing the persistance issues that are causing test failures in this PR. So I think ideally I'd merge #11955 into this PR and then merge the whole changeset as a single change. I'm not merging yet so that you can review more easily - first my answers to your requests in this PR and then the followup PR that builds on top of it.

[JaroslavTulach]

I believe the abstraction of algorithms into singletonizers and their usage is correct. I don't feel completely qualified to talk about the static analysis, but I left few comments inline. If the CI is green, then I am for integrating these changes.

[JaroslavTulach]

I assume this is a reasonable way to avoid the static type information to be stored in the caches.

[radeusgd]

Yes, plus IIRC it fixes a weird behaviour - that even if caches were disabled, they would still be written after compilation or something.

Now, if we run --no-ir-cache, we neither read nor write the caches, which I think is correct.

[JaroslavTulach]

The reason why we are seeing failures like https://github.com/enso-org/enso/actions/runs/12680614808/job/35342759884?pr=12023#step:7:2875 is probably because of this nor write behavior. Previously there was one failing run and the bad caches would get overwritten. Now the bad caches stick there forever.

That's rational, but looks like the

enso/engine/runtime-benchmarks/src/main/java/org/enso/compiler/benchmarks/module/ImportStandardLibrariesBenchmark.java

Line 129 in cb72487

throw new AssertionError("Unexpected output (errors?) from the compiler: " + out.toString());

may not be ready for that!

[radeusgd]

Oh...

Can't we just run the engine with --compile to write the new caches, before running this bench?

[JaroslavTulach]

That would indeed be ideal! The integration of the runtime-compiler into VSCode is blocked right now because we have no way to run the runtime-compiler without TruffleCompilerContext right now. If only these tests could be moved to runtime-compiler project test directory! Then:

• they wouldn't depend on TruffleCompilerContext
• they would need an independent compiler context implementation
• such an implementation could be used in VSCode as well

I remember @Akirathan was once dreaming about using runtime-compiler in VSCode and this was a huge "known unknown".

[radeusgd]

Yes I think ideally we should move them there - it seems like the right direction.

But implementing the independent compiler context is definitely a task for a separate PR.

[radeusgd]

In 6b0ce25 I merged the followup PR so that we can merge them both to develop in one try.

I will proceed with merging once CI gets green.

[radeusgd]

I've ran the benchmarks and tried comparing against develop:
benchs.zip

It's really quite hard to tell in each benchmark if any deviations are just due to benchmark instability or real regression (how are you guys managing to live without seeing the standard deviation error bars on the measurements? 😮).

Here are a few 'more concerning' results I saw:

Still they don't seem bad, so I think I will proceed with merging.