Skip to content

On invalid prefix, throw a TypeError #18061

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

Merged
merged 2 commits into from
Jun 26, 2023
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 26, 2023

Previously, the type was set to UnspecifiedErrorType. But that violates the rule that every ErrorType has to be reported. If that does not happen, crashes in pickler will result.

Fixes #18058

Previously, the type was set to UnspecifiedErrorType. But that violates the rule
that every ErrorType has to be reported. If that does not happen, crashes in
pickler will result.
Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

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

Should type G = (f: _ <: F) => f.A not be able to compile?

@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

I don't think it should compile. f does not have a type we can use.

@dwijnand
Copy link
Member

The test case goes through typedFunctionType's typedDependent, which encodes the function as a RefinedTypeTree, using an approximate AppliedTypeTree refined by the more specific param-dependant type. For f.A we use nonDependentResultApprox to get the "least supertype of resultType that does not contain parameter dependencies". Wouldn't F#A's supertype Any be that supertype? My thinking is perhaps the issue is that <: F should be handled in the typemap's derivedSelect before failing in withPrefix...

Other that that, my change was to avoid a compiler crash caused by an assertion error. I see now that using a TypeError makes the whole typedFunctionType fail and then associate the error message to the function tree, which looks good.

So I think perhaps this should compile, but not crashing in pickling is progress.

@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

We could widen to Any, but that's no enough. The problem is we are writing a dependent function type, which is expanded to a generic type (that's where the avoid map was applied) and also an apply method. The apply method does not have a reasonable type either.

@odersky odersky merged commit 668b160 into scala:main Jun 26, 2023
@odersky odersky deleted the fix-18058 branch June 26, 2023 16:13
@clavigne
Copy link
Contributor

Thanks for the prompt fix!

@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
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.

Dependent function type with a wildcard argument crashes the compiler
4 participants