Implement private constructors & deconstructors/getters for types

[Akirathan]

Created from the discussion github.com/orgs/enso-org/discussions/7088

Follow-up of #7304

Tasks

Preview Give feedback

1. Implement private constructors
2. Ensure that all the construcors in a type are either public or private (See the edit section of the discussion)
3. Verify field getters aren't exposed to public
4. Compilation check of private constructors in pattern matching

Related to:

• Implement private types #8835
• Implement private methods #8834

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-12):

Progress: - Looking into the parser - let's try to tweak it so that atom constructor can be private.

• Merged GraalVM 24.0.0 update (Update to GraalVM 24.0.0 #9647) after some CI fighting. It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-15):

Progress: - Looking into the parser implementation. It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-16):

Progress: - Implemented private constructor handling in Rust parser, and on the Java side as well.

• Writing some compiler test.
• Writing a new compiler pass that ensures that all constructors are either public or private in a type.] It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-17):

Progress: - Writing runtime access checks for private constructors.

• Designing how the runtime access will work.
  • Polyglot code cannot access anything private.
  • Don't fiddle with Truffle's Frame arguments - no need for that. It should be sufficient to check the accessibility when resolving the symbol before the constructor is called.
• JPMS module system troubleshooting. It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-18):

Progress: - Preliminary runtime access check implemented. Already have some tests passing.

• The runtime access check is defined on Function. So in the future, implementing private methods should be simple - just modification in parser. It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-19):

Progress: - Marked the PR as ready for review.

• Runtime checks work, the only thing left to do is to properly specify how the polyglot access should work.
  • Should it throw a panic error when a private field is accessed? Should the private field be invisible? It should be finished by 2024-04-19.

[enso-bot]

Pavel Marek reports a new 🔴 DELAY for today (2024-04-22):

Summary: There is 7 days delay in implementation of the Implement private constructors & deconstructors/getters for types (#8836) task.
It will cause 7 days delay for the delivery of this weekly plan.

The initial estimate was too optimistic. Also, I have to tackle other issues in the meantime.

Delay Cause: This PR is bigger than expected. We also have a lot of review comments to integrate.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-22):

Progress: - Integrating a lot of review comments

• Fixing pattern matching on private constructors
  • This can be done during compilation.
  • Adding more tests, modifying the appropriate compiler passes. It should be finished by 2024-04-26.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2024-04-23):

Progress: - Implementing compile-time check of pattern matching on private constructors. It should be finished by 2024-04-26.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-24):

Progress: - Trying to check all the resolved symbols in IR for private-access.

• There is already a lot of metadata in the IR from previous passes, it should be enough to throw compilation error when private constructor is accessed. It should be finished by 2024-04-26.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-25):

Progress: - Fixing some last review requests.

• Throwin compiler error when a private entity is just referenced is not possible.
• Probably discovered the issue with transient UnresolvedMethod(==) - [WIP] Add logging for UnresolvedMethod bug #9763 (comment) It should be finished by 2024-04-26.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-04-26):

Progress: - Stucked on Rust borrow checker, waiting for Kaz to help with the parser changes.

• Looking into the problems with TCO and panics.
  • It seems that the problem is in the way we detect potential tail calls in the compilation It should be finished by 2024-04-26.