Check for explicit result types in public API

[lefou]

So, I don't have much experience with scalafix. I'd expect that this change should detect / modify a lot of sources where we have missing type annotations, but it doesn't. Any help is welcome.

[lihaoyi]

is it just --check that doesnt work, but fix does? If so we could go back to the earler git diff way of checking and failing in CI

[lefou]

is it just --check that doesnt work, but fix does? If so we could go back to the earler git diff way of checking and failing in CI

Unfortunately not. A pure __.fix does change exactly nothing, but I'm pretty sure we still have a lot of public defs without explicit return types.

[ckipp01]

So this is a bit random, but I dug into this a bit since when trying to run a scalafix rule from within Metals it also fails with a TextDocument.uri not found, which doesn't make a ton of sense. For example I have a very minimal hello world project with a build like this:

import mill._, scalalib._

object millTest extends ScalaModule {
  def scalaVersion = "2.13.12"
}

And then I do have a milltest/src/example/Hello.scala. The error message I was getting from Scalafix was

SEVERE: Internal error: scala.meta.internal.metals.ScalafixProvider$ScalafixRunException: TextDocument.uri not found: milltest/src/example/Hello.scala
java.util.concurrent.CompletionException: scala.meta.internal.metals.ScalafixProvider$ScalafixRunException: TextDocument.uri not found: milltest/src/example/Hello.scala

This comes from here in Scalafix. It was totally by chance that it then clicked.

There is a mistake here that I made that Mill doesn't care about. My module name is millTest, but my directory structure is milltest. Therefore Scalafix will do the lookup for the text document at META-INF/semanticdb/milltest since that's the file structure, but it's actually at META-INF/semanticdb/millTest to match the module name. This causes scalafix to puke and not find a document for the file. I can reproduce this in a minimal hello world project, but my guess would be that in your Mill build you may also have a directory structure with names that maybe differ from the module name? The same thing could be happening here.

[lefou]

@ckipp01 Thanks for commenting. From looking at all the semanticdb file paths, I can't detect any misfitting path names. Also, shouldn't the error message pop up somewhere in that case anyways?

Just in case you're suspicios (like me) whether it could be related to how Mill generates semanticdb data, I have to say, I tried out mill-scalafix a long time ago (maybe 2-3 years?), even before it started to use Mill's semanticDbData target, and had a very same experience. Nothing seemed to work, so I never gave much attention to all the scalafix news. (I think I even tried to use scalafix when migrating Mill 0.6.x to 0.7.x, from Scala 2.12 to 2.13, but it was fruitless to me.) As all of this is on Mill repos, there might be other hidden assumptions in scalafix?

[lefou]

I guess, I'll open an issue in mill-scalafix as well.

[tgodzik]

Manually running Scalafix in Metals looks to be working.

[lefou]

I'm able to reproduce the issue in a mill-scalafix integration test, so this seems to be an upsteam bug.

• Feed to whole classpath to scalafix and fix ExplicitResultTypes joan38/mill-scalafix#172
• ExlicitResultTypes fix is not working joan38/mill-scalafix#174