Disallow export all syntax

[Akirathan]

Investigation of #10043 revealed that the exports resolution is very slow. The algorithm in ExportsResolution is complicated and slow. The main reason is how the export cycles are detected. If we disallow from ... export all (and obivously also from ... export all hiding ...) syntax, the algorithm could be vastly simplified. One of the main problems is how to export extension methods. Currently, extension methods are exported, e.g., via from Standard.Base.Data.Json.Extensions export all and there is no way how to export a single extension method.

---

As part of this task, let's export extension method via their names. For example:

Text.extension_method = ...
Json.extension_method = ...
extension_method = ...

from project.Module export extension_method

would export both Text.extension_method and Json.extension_method, as well as the static method defined on the module.

---

Blocks #10043

### Tasks
- [x] Extension methods can be exported via method name
- [x] Replace every occurence of `from ... export all` with explicit exports
- [ ] Simplify implementation of [BindingsMap.exportedSymbols](???).

Related:

• https://github.com/enso-org/enso/issues/10370
• https://github.com/enso-org/enso/issues/6729

[enso-bot[bot]]

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

Progress: - Continue #9236 with disallowing from ... export all syntax (#10258) It should be finished by 2024-06-17.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-13):

Progress: - Enabling exports of extension and conversion methods by name.

• Minor changes to the IR required, some compiler passes still does not propagate the necessary changes.
  • Looking into what appears to be a recent regression of importStdLibs benchmarks.
• Local measurements were inconclusive. It should be finished by 2024-06-17.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-14):

Progress: - Fixed registering static methods in ModuleScope in IrToTruffle.

• So far, we are only registering module methods in the ModuleScope in IrToTruffle.
  • Fixing looking up of conversion methods and registering them in ModuleScope in IrToTruffle. It should be finished by 2024-06-17.

[enso-bot[bot]]

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

Progress: - Fixing tests, seems like the changes necessary for this will be more intrusive than I originally expected. It should be finished by 2024-06-17.

[enso-bot[bot]]

Pavel Marek reports a new 🔴 DELAY for yesterday (2024-06-19):

Summary: There is 7 days delay in implementation of the Disallow export all syntax (#10258) task. It will cause 7 days delay for the delivery of this weekly plan.

Moreover, I am dealing with moving from an appartnment to a new house, so I am a bit busy with that.

Delay Cause: Bumped into some unexpected complications with the implementation.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for yesterday (2024-06-19):

Progress: - Still fixing a lot of tests and compilation errors.

• Having one symbol resolved to multiple entities is a bit tricky to handle, since our previous implementation was not designed to handle this. It should be finished by 2024-06-24.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-20):

Progress: - Fixing GlobalNames pass to add more metadata for static method calls.

• There seems to be one more test to fix in JVM tests. To fix that, I need to check metadata generated in various compiler passes. It should be finished by 2024-06-24.

[enso-bot[bot]]

Pavel Marek reports a new 🔴 DELAY for today (2024-06-25):

Summary: There is 4 days delay in implementation of the Disallow export all syntax (#10258) task. It will cause 4 days delay for the delivery of this weekly plan.

Delay Cause: Need to tackle the follow-up PR for the same issue.

[enso-bot[bot]]

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

Progress: - Merged the extension methods can be exported by name.

• Created follow-up PR - disallow export all syntax.
  • Looking into how to disallow that in the Rust parser.
  • all and hiding fields are not necessary for the Export token. It should be finished by 2024-06-28.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-27):

Progress: - Struggling with fixes for exporting constructors from types.

• Import export resolution algorithm does not currently support constructors as import targets.
• Trying to modify the algorithm to support this case. It should be finished by 2024-06-28.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-06-28):

Progress: - Continue with the simplification of export resolution.

• Increasing test coverage, refactoring.
• I have broken the exportedSymbols field construction in BindingsMap, so I am trying to test it and fix it.
• Created related issue (incosistent imports) #10399. It should be finished by 2024-06-28.

[enso-bot[bot]]

Pavel Marek reports a new 🔴 DELAY for today (2024-07-01):

Summary: There is 7 days delay in implementation of the Disallow export all syntax (#10258) task. It will cause 7 days delay for the delivery of this weekly plan.

Delay Cause: Still dealing with many failing tests.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-07-01):

Progress: - Continue fixing tests

• Fixing renamed exports
• Will have to check if the size of BindingsMap did not increase significantly.
• Compilation is already visibly faster - compiling all std libraries takes 90s instead of 180s. It should be finished by 2024-07-05.