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

Make FQN and imports consistent #9367

Closed

Conversation

Akirathan
Copy link
Member

@Akirathan Akirathan commented Mar 11, 2024

Fixes #9329 and #6553

Pull Request Description

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,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@Akirathan Akirathan self-assigned this Mar 11, 2024
@Akirathan Akirathan added the CI: No changelog needed Do not require a changelog entry for this PR. label Mar 12, 2024
@JaroslavTulach
Copy link
Member

I believe the tests are now covering every type we have in the Standard.Base and more. I can see we have nice failures all over. That's a great coverage. Now we need a fix!

May I ask whether my patch fixes the failing tests? If so, I suggest to apply it, integrate and move on.

The only objection I heard against my fix was: it doesn't solve the problem on the IR level. However I have a stronger and stronger feeling our IR is wrong and we will not be able to keep it in the future anyway. The IR passes are slow and not ready for incremental compilation to name at least two drawbacks.

@Akirathan Akirathan linked an issue Mar 14, 2024 that may be closed by this pull request
@Akirathan
Copy link
Member Author

May I ask whether #9329 (comment) fixes the failing tests? If so, I suggest to apply it, integrate and move on.
The only objection I heard against #9329 (comment) was: it doesn't solve the problem on the IR level. However I have a stronger and stronger feeling our IR is wrong and we will not be able to keep it in the future anyway. The IR passes are slow and not ready for incremental compilation to name at least two drawbacks.

@JaroslavTulach Your patch fixes 9 out of 11 failing test cases. You are probably right about the IR generation - let's try to implement this in the InvokeMethodNode. I will try to modify your patch to pass also the remaining tests. And just to be sure, I will also provide tests for exported symbols from other libraries.

@Akirathan
Copy link
Member Author

Akirathan commented Mar 22, 2024

After a lot of struggling with IR passes and their (almost arbitrary) changes to the IR, I have contributed a simple IRDumper that dumps an IR into a GraphViz text file format (which is even simpler than JSON by the way). An example of PNG created from some of these files:
local Test_Fully_Qualified_Name_Conflict Main gv

@Akirathan
Copy link
Member Author

This PR might be dropped in favor of #9539.

@enso-bot enso-bot bot mentioned this pull request Mar 26, 2024
@JaroslavTulach
Copy link
Member

JaroslavTulach commented Mar 29, 2024

This PR might be dropped in favor of #9539.

Yes, I think this PR doesn't need to be integrated. All related issues are already fixed.

@farmaazon farmaazon deleted the wip/akirathan/9329-incosistent-import-and-fqn branch May 9, 2024 10:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

Inconsistent import and FQN Fully Qualified Name reference not resolved correctly
2 participants