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 toplevel opaque types transparent to the whole file #21530

Closed
wants to merge 1 commit into from

Conversation

dwijnand
Copy link
Member

@dwijnand dwijnand commented Sep 2, 2024

Fixes #15050

@@ -1620,6 +1620,7 @@ class TypeComparer(@constructorOnly initctx: Context) extends ConstraintHandling

def findEnclosingThis(moduleClass: Symbol, from: Symbol): Type =
if ((from.owner eq moduleClass) && from.isPackageObject && from.is(Opaque)) from.thisType
else if (from eq moduleClass.owner) && moduleClass.isTopLevelDefinitionsObject && moduleClass.is(Opaque) then moduleClass.thisType
Copy link
Member

Choose a reason for hiding this comment

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

Isn't that going to create a C$.this reference outside of C$? If yes, I don't think that's supposed to be possible/valid.

Copy link
Member Author

Choose a reason for hiding this comment

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

The reference wasn't outside when the user wrote it. The compiler moved it so it's nested in a package object, but to the user the call site isn't from "outside".

Copy link
Member

@sjrd sjrd Sep 2, 2024

Choose a reason for hiding this comment

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

I understand, but still ... from an elaborated, TASTy-level point of view, this is invalid. A C.this reference has no meaning outside of C. This is worse than being "not accessible" because of protected or even "not visible" because of private; here it does not even exist.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd argue that C.this, where C is a singleton module is just an alternative to C.type. Which, btw, is what widenInferred does as a final cleanup.

Copy link
Member

Choose a reason for hiding this comment

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

I'd argue that C.this, where C is a singleton module is just an alternative to C.type.

It represents the same set of values at run-time, sure, but it's not valid everywhere C.type is valid.

Which, btw, is what widenInferred does as a final cleanup.

AFAICT, widentInferred turns pre.C$ into pre.C; not C$.this into pre.C nor the converse.

@dwijnand dwijnand closed this Nov 6, 2024
@dwijnand dwijnand deleted the fix-opaque-select branch November 6, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Weird opaque types behaviour
2 participants