Simplify `BindingsMap` by instead relying on `StaticModuleScope` for atom type resolution #11955

radeusgd · 2024-12-31T17:42:46Z

Pull Request Description

Removing AtomTypeInterface - it was a useful temporary hack, but in the longer term it seemed to not really solve the problem we had.
Now storing the types of atom constructor arguments in StaticModuleScope, so I can remove the Expression from BindingsMap. I think that storing IR inside of metadata attached to said IR (which was the reason for introducing cycles) was a bad idea after all.
Thus, the TypeRepresentation is greatly simplified - it no longer refences complicated objects like AtomTypeInterface (which had a nice API but ugly internals, and the internals were affecting serialization). Now TypeRepresentation becomes just plain data, a much simpler representation and I think it is closer to what it was supposed to be from the beginning.

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 · 2025-01-02T19:02:34Z

engine/runtime-compiler/src/main/scala/org/enso/compiler/data/BindingsMap.scala

-  case class Argument(
-    name: String,
-    hasDefaultValue: Boolean,
-    typReference: Reference[Expression]
-  ) {
-    def typ(): Option[Expression] = Option(
-      typReference.get(classOf[Expression])
-    )
-  }


This removes the infamous cycle from the IR - the Expression holding the type of the constructor is no longer needed.

That's because we process this type Expression in StaticModuleScopeAnalysis and save it in StaticModuleScope metadata as an already processed TypeRepresentation - so it is no longer IR that is stored inside of metadata, but a simpler data structure representing our types.

This is a minimal change to the BindingsMap. It removes typ() which wasn't used by regular execution at all - e.g. everything shall keep functioning...

Yep, typ() was only added for the type inference and now it is obsolete thanks to StaticModuleScope, so it can be removed. In a way - I revert BindingsMap to be like before my earlier changes.

radeusgd · 2025-01-02T19:03:14Z

...iler/src/main/java/org/enso/compiler/pass/analyse/types/scope/StaticModuleScopeAnalysis.java

      registerFieldGetters(scopeBuilder, atomTypeScope, typ);
    }

+    private TypeRepresentation buildAtomConstructorType(


This is mostly moved from the TypeResolver.

radeusgd · 2025-01-02T19:04:55Z

.../runtime-compiler/src/main/java/org/enso/compiler/pass/analyse/types/TypeRepresentation.java

@@ -51,8 +51,7 @@ public QualifiedName getAssociatedType() {
   * <p>Instances that are assigned this type are built with one of the available constructors, but
   * statically we do not necessarily know which one.
   */
-  record AtomType(QualifiedName fqn, AtomTypeInterface typeInterface)
-      implements TypeRepresentation {
+  record AtomType(QualifiedName fqn) implements TypeRepresentation {


Our type representation is no longer holding references to some complex AtomTypeInterface structure which internally was holding references to BindingsMap and was overall ugly.

Now the TypeRepresentation is a plain data type. The information about Atom type interface is instead encoded in the StaticModuleScope, like information about method already has been.

radeusgd · 2025-01-02T19:12:34Z

@JaroslavTulach shall we maybe disable the support for cycles in IR persistence now?

I think we are no longer relying on it and there were issues with it from time to time so maybe we should change the code to fail on cycles and keep an eye on us accidentally re-introducing these problematic cycles?

btw. I think the cycles could have been also why @Akirathan could not use equality for comparing IR and had to resort to identity. I'm not sure if we had any other cycles than this one? If not, maybe we could try to come back to equality over identity then.

JaroslavTulach

I don't see any problem with the changes into BindingsMap.

engine/runtime-compiler/src/main/java/org/enso/compiler/pass/analyse/types/scope/AtomType.java

JaroslavTulach · 2025-01-07T14:58:49Z

engine/runtime-compiler/src/main/scala/org/enso/compiler/data/BindingsMap.scala

-  case class Argument(
-    name: String,
-    hasDefaultValue: Boolean,
-    typReference: Reference[Expression]
-  ) {
-    def typ(): Option[Expression] = Option(
-      typReference.get(classOf[Expression])
-    )
-  }


This is a minimal change to the BindingsMap. It removes typ() which wasn't used by regular execution at all - e.g. everything shall keep functioning...

engine/runtime-integration-tests/src/test/java/org/enso/compiler/test/TypeInferenceTest.java

...iler/src/main/java/org/enso/compiler/pass/analyse/types/scope/StaticModuleScopeAnalysis.java

…n next iteration" This reverts commit 5be3b82.

…uleScope

…sing out AtomTypeInterface

…d, we are on good path Expected x1 = ((My_Constructor) 1) to have the right atom type: expected:<[project.modA.My_Type]> but was:<[Standard.Base.Data.Numbers.Float]>

JaroslavTulach · 2025-01-08T04:13:31Z

btw. I think the cycles could have been also why @Akirathan could not use equality for comparing IR and had to resort to identity. I'm not sure if we had any other cycles than this one? If not, maybe we could try to come back to equality over identity then.

the equality problem isn't related to cycles, but to mutability inside of immutable objects - MetadataStorage is mutable - structural equals in copy isn't enough #11513

change the code to fail on cycles

It doesn't cause us much problems/slowdown on read, especially when cycles aren't present. So it doesn't have any priority. I'd like to avoid an issue laying around in new/backlog that would need to be ignored every planning meeting.

…11399) - Implements #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 #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`.

radeusgd mentioned this pull request Jan 2, 2025

Infer method calls on known types and warn about nonexistent methods #11399

Merged

5 tasks

radeusgd force-pushed the wip/radeusgd/type-checker-atom-type-in-static-module-scope branch from 31934b9 to 919086a Compare January 2, 2025 18:05

radeusgd commented Jan 2, 2025

View reviewed changes

radeusgd self-assigned this Jan 2, 2025

radeusgd added the CI: No changelog needed Do not require a changelog entry for this PR. label Jan 2, 2025

radeusgd marked this pull request as ready for review January 2, 2025 19:05

radeusgd requested review from 4e6, JaroslavTulach, hubertp and Akirathan as code owners January 2, 2025 19:05

radeusgd changed the title ~~[Draft] Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution~~ Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution Jan 2, 2025

JaroslavTulach approved these changes Jan 7, 2025

View reviewed changes

radeusgd added 15 commits January 7, 2025 18:27

Revert "remove AtomType stub - it was not finished - to be re-added i…

e3a72a7

…n next iteration" This reverts commit 5be3b82.

WIP

21a541b

WIP replacing BindingsMap access and AtomTypeInterface with StaticMod…

ecd3ca1

…uleScope

fmt after rebase

9d3d66f

finish implementing the logic in StaticModuleScopeAnalysis, start pha…

31c4975

…sing out AtomTypeInterface

WIP phasing out old part - find usages and how to replace them>

b5881b6

remove old AtomTypeInterface

9d02147

delete obsolete helpers

65b0cee

add test for imported constructor

870c37b

experiment: returning Any->Float will change test behaviour? yes. goo…

92e7430

…d, we are on good path Expected x1 = ((My_Constructor) 1) to have the right atom type: expected:<[project.modA.My_Type]> but was:<[Standard.Base.Data.Numbers.Float]>

resolve imported ctor, fixing the test

2427e14

add test for later

6d3bedf

remove obsolete debug print

588bbee

fmt

a2d3889

add test for reporting a warning on nonexistent atom constructor

94c2b98

radeusgd added 7 commits January 7, 2025 18:30

fmt after merge

db95ded

rename

3e7919c

fix after merge

0726ca9

comment

d913ce7

CR: comments

5432f67

update invalidated passes

53f1930

CR: use ScalaConversions where it makes more sense

5f515ff

radeusgd force-pushed the wip/radeusgd/type-checker-atom-type-in-static-module-scope branch from 4e6cd00 to 5f515ff Compare January 7, 2025 17:59

fix pass invalidation

1c2a51a

radeusgd merged commit 6b0ce25 into wip/radeusgd/9812-infer-method-calls Jan 7, 2025
29 of 31 checks passed

radeusgd deleted the wip/radeusgd/type-checker-atom-type-in-static-module-scope branch January 7, 2025 18:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify `BindingsMap` by instead relying on `StaticModuleScope` for atom type resolution #11955

Simplify `BindingsMap` by instead relying on `StaticModuleScope` for atom type resolution #11955

radeusgd commented Dec 31, 2024 •

edited

Loading

radeusgd Jan 2, 2025

JaroslavTulach Jan 7, 2025

radeusgd Jan 7, 2025

radeusgd Jan 2, 2025

radeusgd Jan 2, 2025

radeusgd commented Jan 2, 2025

JaroslavTulach left a comment

JaroslavTulach Jan 7, 2025

JaroslavTulach commented Jan 8, 2025

Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution #11955

Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution #11955

Conversation

radeusgd commented Dec 31, 2024 • edited Loading

Pull Request Description

Important Notes

Checklist

radeusgd Jan 2, 2025

Choose a reason for hiding this comment

JaroslavTulach Jan 7, 2025

Choose a reason for hiding this comment

radeusgd Jan 7, 2025

Choose a reason for hiding this comment

radeusgd Jan 2, 2025

Choose a reason for hiding this comment

radeusgd Jan 2, 2025

Choose a reason for hiding this comment

radeusgd commented Jan 2, 2025

JaroslavTulach left a comment

Choose a reason for hiding this comment

JaroslavTulach Jan 7, 2025

Choose a reason for hiding this comment

JaroslavTulach commented Jan 8, 2025

Simplify `BindingsMap` by instead relying on `StaticModuleScope` for atom type resolution #11955

Simplify `BindingsMap` by instead relying on `StaticModuleScope` for atom type resolution #11955

radeusgd commented Dec 31, 2024 •

edited

Loading