8000 [WIP] Preserve singleton type when inferring override by som-snytt · Pull Request #10334 · scala/scala · GitHub
[go: up one dir, main page]

Skip to content

[WIP] Preserve singleton type when inferring override #10334

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

Closed

Conversation

som-snytt
Copy link
Contributor

@scala-jenkins scala-jenkins added this to the 2.13.11 milestone Mar 5, 2023
@som-snytt
Copy link
Contributor Author
som-snytt commented Mar 5, 2023

I expected something like this simple retronymism from ten years ago ("Better return type inheritance for dep. method types"):

          // SI-7668 Substitute parameters from the parent method with those of the overriding method.
          overriddenTp = overriddenTp.substSym(overridden.paramss.flatten, vparamss.flatten.map(_.symbol))

which currently reads

            // scala/bug#7668 Substitute parameters from the parent method with those of the overriding method.
            val overriddenResTp = applyFully(overriddenTp, vparamSymss).substSym(overriddenTparams, tparamSkolems)

where applyFully is the locus of intervention.

(First swing was to unpack the existential in assignTypeToTree. The current swing avoids using resultType which does the ExistentialExtrapolation. I did not formulate an escape hatch in existentialAbstraction that didn't break the more usual dependent case that returns x.T instead of x.type.)

Quick test, the (correct) escape hatch at existentialAbstraction means i 8000 nferring sb.type but we need xb.type for typechecking RHS.

t12621.scala:13: error: type mismatch;
 found   : xb.type (with underlying type StringBuilder)
 required: sb.type
  override def f(xb: StringBuilder) = xb    // inferred StringBuilder

Adding a neg test that shows the correct required type.

I notice the other PR doesn't fail that compilation.

@som-snytt som-snytt force-pushed the issue/12621-override-inference branch from e0b8c58 to 401a046 Compare March 5, 2023 19:34
@som-snytt som-snytt marked this pull request as ready for review March 5, 2023 19:59
@som-snytt som-snytt modified the milestones: 2.13.11, 2.13.12 Mar 6, 2023
@som-snytt som-snytt force-pushed the issue/12621-override-inference branch from 401a046 to 85c18a6 Compare March 16, 2023 18:04
@som-snytt som-snytt changed the title Preserve singleton type when inferring override [ci: last-only] Preserve singleton type when inferring override Mar 16, 2023
@som-snytt som-snytt force-pushed the issue/12621-override-inference branch from 85c18a6 to 236ccba Compare March 16, 2023 18:07
Update comment on nullary/nilary distinction.
@som-snytt som-snytt force-pushed the issue/12621-override-inference branch from 236ccba to 52de86b Compare March 20, 2023 06:15
@SethTisue SethTisue marked this pull request as draft March 20, 2023 14:58
@som-snytt
Copy link
Contributor Author

This does seem to be an inconsistent test:

% diff /home/jenkins/workspace/scala-2.13.x-validate-main/test/files/presentation/doc.check /home/jenkins/workspace/scala-2.13.x-validate-main/test/files/presentation/doc-presentation.log
@@ -1,2 +1,3 @@
 warning: 1 deprecation (since 2.13.0); re-run with -deprecation for details
 reload: Base.scala, Class.scala, Derived.scala
+Unexpected foo method comment:None

@lrytz
Copy link
Member
lrytz commented Apr 11, 2023

+Unexpected foo method comment:None

yes, seen that before

@som-snytt som-snytt closed this Jun 5, 2023
@SethTisue SethTisue removed this from the 2.13.12 milestone Jun 10, 2023
@som-snytt som-snytt changed the title Preserve singleton type when inferring override [WIP] Preserve singleton type when inferring override Jan 27, 2024
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.

Bad inference of override with dependent result
4 participants
0