Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace all from ... export all with explicit exports #10369

Merged
merged 112 commits into from
Jul 11, 2024

Conversation

Akirathan
Copy link
Member

@Akirathan Akirathan commented Jun 25, 2024

Follow-up of #10274. Partially fixes #10258, #6729, #9236

Pull Request Description

Replaces all from ... export all with explicit by-name exports.

Important Notes

  • Remove isAll and hiding fields from Export IR
  • Static or extension method can be imported by name
  • Simplify exports resolution algorithm
  • A new ConflictingResolutionsError compiler error is thrown when there are conflicting resolutions in a module.
  • For exmple, a conflicting resolution is a type defined in the module that has the same name as a different submodule.
  • Previously, this was reported as a warning, but it would now cause issues for the export resolution, so an error is thrown earlier.
  • Add a lot of tests for BindingsMap.
  • Add tests for various steps of ExportsResolution.
    • We used to have 0 unit tests for this, as well as for BindingsMap.

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.

@Akirathan Akirathan self-assigned this Jun 25, 2024
@Akirathan Akirathan added CI: No changelog needed Do not require a changelog entry for this PR. CI: Clean build required CI runners will be cleaned before and after this PR is built. labels Jun 25, 2024
docs/syntax/imports.md Outdated Show resolved Hide resolved
docs/syntax/imports.md Show resolved Hide resolved
docs/syntax/imports.md Show resolved Hide resolved
docs/syntax/imports.md Show resolved Hide resolved
@Akirathan Akirathan marked this pull request as ready for review July 10, 2024 16:30
from project.Meta.Enso_Project export enso_project
from project.Network.Extensions export all
from project.System.File_Format export Auto_Detect, Bytes, File_Format, Infer, JSON_Format, Plain_Text_Format
export project.Data.Boolean.Boolean
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is from ... export deprecated even when it's not using all?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are not deprecated, they are just now suffering from #10399. Until that issue is fixed, rule of a thumb is to just use plain export ....

Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving the libs bits.

@JaroslavTulach
Copy link
Member

Failing tests:

Close, so close...

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great to see all tests are green! I am looking forward to see the speedup after integration.

@Akirathan
Copy link
Member Author

There is not enough time to run proper benchmarks before integration. But I have at least run some benchmarks locally (lower score is better - ms/op):

Benchmark name Old score New score
ImportStandardLibrariesBenchmark 219 58
ManyErrorsBenchmark 77 74
ManyLocalVarsBenchmark 32 25
ManyNestedBlocksBenchmark 51 46
ManySmallMethodsBenchmark 114 106

Moreover, local experiments with running

enso --no-compile-dependencies --no-global-cache --no-ir-caches --no-read-ir-caches --compile Base

revealed that compilation of Standard.Base now takes 6 seconds, versus the old 31 seconds.

@Akirathan
Copy link
Member Author

Done a brief QA with the IDE and everything seems fine. Integrating ...

@Akirathan Akirathan merged commit 0f9852a into develop Jul 11, 2024
41 checks passed
@Akirathan Akirathan deleted the wip/akirathan/10258-disallow-export-all branch July 11, 2024 17:34
export in `A_Module.enso`:

```
export project.A_Module.export
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should have been:

- export project.A_Module.export
+ export project.A_Module.method

if (parts.size() < 3) {
return null;
}
var constructors = definedConstructors(imp);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to return a Map here? Then the O(N) stream filter could potentially become an O(log N) / O(1) map access.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also looking at the code it seems like we are constructing this on each call. Have you considered caching the result? I'm not sure how many times this is called, but I'd assume it can be called a lot on heavily used modules, so avoiding to re-construct this List (or Map) every time could give us some additional speedup.

Comment on lines +22 to +24
* Ensures that all the symbols that are exported exist. If not, an IR error is generated. It is not
* a {@link IRPass compiler pass} because it needs access to {@link
* org.enso.compiler.PackageRepository}. Ignores renamed exports.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the explanation why this isn't a compiler pass.

I mean I'm not convinced it has to be.

But we can access PackageRepository in passes, I've been doing this for #9812.

var packageRepo = moduleContext.pkgRepo().isDefined() ? moduleContext.pkgRepo().get() : null;

or is something wrong about this pattern?

mergify bot pushed a commit that referenced this pull request Jul 15, 2024
Vast majority of CPU time in ExportsResolution is spent in [BindingsMap.SymbolRestriction.optimize](https://github.com/enso-org/enso/blob/9a373572470ed434fb7b99114553c411ad54718e/engine/runtime-compiler/src/main/scala/org/enso/compiler/phase/ExportsResolution.scala#L173). #10369 dealt with this. This PR only adds the `ExportImportResolutionBenchmark`.

# Important Notes
- Introduce new [ExportImportResolutionBenchmark](https://github.com/enso-org/enso/blob/9e70f675d8c6d60b74733606b1c48f52e55da7ba/engine/runtime-benchmarks/src/main/java/org/enso/compiler/benchmarks/exportimport/ExportImportResolutionBenchmark.java) that measures the performance of import and export resolution only.
- Note that the already existing [ImportStandardLibrariesBenchmark](https://github.com/enso-org/enso/blob/4d49b003752e8771e95d5ae379ce953c85ef020c/engine/runtime-benchmarks/src/main/java/org/enso/compiler/benchmarks/module/ImportStandardLibrariesBenchmark.java) is probably fine for the purpose, but I just wanted to be sure that **ONLY** the import/export resolution is measured and nothing else, so I have isolated that into a new benchmark.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: No changelog needed Do not require a changelog entry for this PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Disallow export all syntax
5 participants