Don't add module's builtins to the scope of a builtin type #3791

hubertp · 2022-10-12T16:21:50Z

Pull Request Description

It appears that we were always adding builtin methods to the scope of the module and the builtin type that shared the same name.
This resulted in some methods being accidentally available even though they shouldn't.

This change treats differently builtins of types and modules and introduces auto-registration feature for builtins.
By default all builtin methods are registered with a type, unless explicitly defined in the annotation property.
Builtin methods that are auto-registered do not have to be explicitly defined and are registered with the underlying type.
Registration correctly infers the right type, depending whether we deal with static or instance methods.

Builtin methods that are not auto-registered have to be explicitly defined always. Modules' builtin methods are the prime example.

Important Notes

Builtins now carry information whether they are static or not (inferred from the lack of self parameter).
They also carry a autoRegister property to determine if a builtin method should be automatically registered with the type.

Checklist

Please include the following checklist in your PR:

The documentation has been updated if necessary.
All code conforms to the
Scala,
Java,
and
Rust
style guides.
All code has been tested:
- Unit tests have been written where possible.
- If GUI codebase was changed: Enso GUI was tested when built using BOTH
  ./run ide build and ./run ide watch.

radeusgd

Looks good, just a few suggestions/questions.

distribution/lib/Standard/Base/0.0.0-dev/src/System/File.enso

...g/enso/interpreter/node/expression/builtin/immutable/FromPolyglotArrayBuiltinVectorNode.java

...untime/src/main/java/org/enso/interpreter/node/expression/builtin/special/RunThreadNode.java

engine/runtime/src/main/java/org/enso/interpreter/runtime/data/Array.java

engine/runtime/src/test/scala/org/enso/interpreter/test/semantic/PolyglotTest.scala

engine/runtime/src/main/scala/org/enso/compiler/phase/ModuleBuiltins.scala

engine/runtime/src/main/scala/org/enso/compiler/codegen/IrToTruffle.scala

lib/scala/interpreter-dsl/src/main/java/org/enso/interpreter/dsl/MethodProcessor.java

engine/runtime/src/main/java/org/enso/interpreter/runtime/builtin/Builtins.java

...-with-instruments/src/test/scala/org/enso/interpreter/test/instrument/BuiltinTypesTest.scala

.../java/org/enso/interpreter/node/expression/builtin/immutable/FromArrayBuiltinVectorNode.java

engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/io/PrintErrNode.java

JaroslavTulach · 2022-10-31T05:25:15Z

engine/runtime/src/main/java/org/enso/interpreter/runtime/builtin/BuiltinFunction.java

+import org.enso.interpreter.runtime.callable.function.Function;
+
+/** BuiltinFunction encapsulates information about a builtin runtime function and its metadata. */
+public class BuiltinFunction {


Wouldn't BuiltinFunction rather be a record than plain class?

Yes, indeed. Except that frgaal appears to be causing problems when I make that change, as noted in the comment one line below.

Yeap, still does it

[error] /home/hubert/tmp/enso/engine/runtime/src/main/java/org/enso/interpreter/runtime/builtin/BuiltinFunction.java:7:15: not found: type java [error] public record BuiltinFunction(Function fun, boolean isStatic, Owner owner) { [error] ^ [error] one error found

this is a weird one.

Is there a simple reproducer that wouldn't involve sbt? Then we can report a bug.

Seems that might be a known caveat - "record classes" section mentions some problems if the target is lower than 16.

It appears that we were always adding builtin methods to the scope of the module and the builtin type that shared the same name. This resulted in some methods being accidentally available even though they shouldn't.

During Builtins initialization we only register non-static builtins. That way one does not have to import stdlib to have basic operations on Any or Number. Similarly during IRtoTruffle for only consider static builtins, thus avoiding a situation where we would try to register them twice. This required changing our annotations processor so that it is aware if a builtin is a static or not, based on the lack or presence of self parameter, respectively. More importantly this approach allows us to avoid hacky solution in types which caused adding module methods to types' scope. And we don't do that late in the interpreter.

Builtin statics are registered differently depending on whether their owner would be a module or a type. The latter can be registered early on because we already have type presents, while the former will be registered during codegen. This distinction allows us to treat all builtins the same. There is no need to make a stub definition of a builtin method - they will all be automatically registered, and the fact if they are static or not is now irrelevant.

Module builtin methods declarations had to be implicitly added at an early stage so that BindingAnalysis (and later passes) can make use of that information. This change adds implicit method definitions for all module builtins unless they have been provided explicitly. With this change one does not have to provide explicit builtin declarations ever, irrespective of whether the owner is a module or a type. Removed some stub definitions to illustrate the usage.

Co-authored-by: Radosław Waśko <[email protected]>

Builtins defined on modules are no longer auto-registered by default. This was suggested to be a more intuitive solution that avoids magic and potential name conflicts for modules using the same name.

hubertp requested a review from kustosz October 12, 2022 16:21

hubertp force-pushed the wip/hubert/builtins-creap-into-type-scope-183403598 branch from fde582a to 01b2b08 Compare October 14, 2022 10:22

hubertp changed the title ~~Don't add builtins to the scope of builtin type~~ Don't add static builtins to the scope of builtin type Oct 14, 2022

hubertp force-pushed the wip/hubert/builtins-creap-into-type-scope-183403598 branch 2 times, most recently from 07f1f90 to 436f7ce Compare October 27, 2022 21:03

hubertp marked this pull request as ready for review October 27, 2022 21:36

hubertp requested review from jdunkerley, radeusgd, 4e6 and JaroslavTulach as code owners October 27, 2022 21:36

radeusgd approved these changes Oct 28, 2022

View reviewed changes

JaroslavTulach approved these changes Oct 31, 2022

View reviewed changes

hubertp force-pushed the wip/hubert/builtins-creap-into-type-scope-183403598 branch from 983efc8 to 16157ae Compare October 31, 2022 10:56

hubertp force-pushed the wip/hubert/builtins-creap-into-type-scope-183403598 branch from c690ad3 to b3c8eed Compare November 15, 2022 15:54

hubertp and others added 16 commits November 15, 2022 17:03

Don't add builtins to the scope of builtin type

774bdf0

It appears that we were always adding builtin methods to the scope of the module and the builtin type that shared the same name. This resulted in some methods being accidentally available even though they shouldn't.

Cleanup

5334add

more cleanup

de00c57

Minor adaptations to latest changes

fedb0a4

nits

a07b785

rebase tweaks

fce1dad

changelog

9909f9b

fmt

9ae2d6d

Remove now obsolete declarations

24224cc

nits

5882049

PR review

f09af2a

Apply suggestions from code review

7387381

Co-authored-by: Radosław Waśko <[email protected]>

PR review + formatting

5ea2d6f

hubertp added 2 commits November 15, 2022 17:03

Use autoRegister rather than owner for builtins

4a0d272

Builtins defined on modules are no longer auto-registered by default. This was suggested to be a more intuitive solution that avoids magic and potential name conflicts for modules using the same name.

Missing builtin declaration in micro-distribution

3c9c0b0

hubertp force-pushed the wip/hubert/builtins-creap-into-type-scope-183403598 branch from b3c8eed to 3c9c0b0 Compare November 15, 2022 16:36

IrToTruffle determines correct builtins to register

a11b5df

hubertp changed the title ~~Don't add static builtins to the scope of builtin type~~ Don't add module builtins to the scope of builtin type Nov 16, 2022

hubertp changed the title ~~Don't add module builtins to the scope of builtin type~~ Don't add module's builtins to the scope of a builtin type Nov 16, 2022

hubertp added the CI: Ready to merge This PR is eligible for automatic merge label Nov 16, 2022

mergify bot merged commit 7b0759f into develop Nov 16, 2022

mergify bot deleted the wip/hubert/builtins-creap-into-type-scope-183403598 branch November 16, 2022 10:23

JaroslavTulach mentioned this pull request Nov 5, 2024

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

Merged

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't add module's builtins to the scope of a builtin type #3791

Don't add module's builtins to the scope of a builtin type #3791

hubertp commented Oct 12, 2022 •

edited

Loading

radeusgd left a comment

JaroslavTulach Oct 31, 2022

hubertp Oct 31, 2022

hubertp Oct 31, 2022

JaroslavTulach Oct 31, 2022

hubertp Nov 15, 2022

Don't add module's builtins to the scope of a builtin type #3791

Don't add module's builtins to the scope of a builtin type #3791

Conversation

hubertp commented Oct 12, 2022 • edited Loading

Pull Request Description

Important Notes

Checklist

radeusgd left a comment

Choose a reason for hiding this comment

JaroslavTulach Oct 31, 2022

Choose a reason for hiding this comment

hubertp Oct 31, 2022

Choose a reason for hiding this comment

hubertp Oct 31, 2022

Choose a reason for hiding this comment

JaroslavTulach Oct 31, 2022

Choose a reason for hiding this comment

hubertp Nov 15, 2022

Choose a reason for hiding this comment

hubertp commented Oct 12, 2022 •

edited

Loading