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

Help implement Metals' infer expected type feature #21390

Merged
merged 7 commits into from
Aug 22, 2024

Conversation

dwijnand
Copy link
Member

@dwijnand dwijnand commented Aug 14, 2024

Apart from helping to implement the new InferExpectedType feature in Metals, I fixed a bug in Applications, which is actually a re-implementation of my fix in #18269, except now it also applies to varargs arguments. Previously, in #18269, I checked the typed args, but varargs specifically removes (dropInPlace) the - possibly error-typed! - var arg args, wrapping them in an not error-typed SeqLiteral tree. Now we record those failures instantly so we don't lose them.

@dwijnand dwijnand force-pushed the infer-expected-type branch from d75e0b2 to 58cec81 Compare August 14, 2024 21:09
Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

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

Thanks for working on this 🎉

@@ -198,6 +199,15 @@ case class ScalaPresentationCompiler(
.asJava
}

def inferExpectedType(params: OffsetParams): CompletableFuture[ju.Optional[String]] =
Copy link
Contributor

Choose a reason for hiding this comment

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

There is already an existing method insertInferredType wouldn't that be the same thing?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is just for the purpose of testing. The method will be used only inside of pc by such things like completions. This covers more cases then insertInferredType but doesn't change it into textEdit. We could have insertInferredType cover those cases too but I don't think it's ever useful.

import scala.meta.pc.OffsetParams
import scala.meta.pc.SymbolSearch

class InferExpectedType(
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we instead reuse this or parts of it in InferredTypeProvider?

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems that InferredTypeProvider still processes path to figure out where to add edit and if/what parenthesis should be added. So I'm not sure there is any benefit in this.

@dwijnand

This comment was marked as resolved.

@dwijnand dwijnand force-pushed the infer-expected-type branch from 58cec81 to 53ba3c8 Compare August 17, 2024 22:40
@michelou
Copy link
Contributor

@dwijnand Thanks for adding private def instDecision(...) in typer/Inferencing.scala. It makes the reasoning more clear.

TypeComparer.explaining is like TypeComparer.explained, but instead of
just returning the trace, returns the result, still allowing the trace
to be accessed via .lastTrace, as exemplified by implementing
TypeComparer.explained in terms of TypeComparer.explaining.

Also add, but leave commented out the call of, a trace.dumpStack, which
is like Thread.dumpStack(), but outputing to System.out, like all our
tracing does - so the two don't interact when unbuffering onto the
terminal.  Also, we can do customisations like filtering out stack
elements, limiting the stack.
But keep the extraction of the instDecision logic, and keep the tests
cases I used in studying this change.

Also simplify and update InstantiateModel.  Martin had tweaked my i14218
fix to make it more conservative: in the (NN, UU) case (i.e. no inferred
bounds, only a UU upper bound declared) for covariant type parameters,
revert back to minimising to Nothing rather than maximising to the
declared bound.
@dwijnand dwijnand force-pushed the infer-expected-type branch from 5615ef1 to 43fc10c Compare August 21, 2024 13:06
@dwijnand dwijnand marked this pull request as ready for review August 21, 2024 16:40
@dwijnand dwijnand requested a review from SethTisue August 21, 2024 16:41
Copy link
Member

@SethTisue SethTisue left a comment

Choose a reason for hiding this comment

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

I don't know the typer deeply enough to be fully confident this is mergeable. But the changes do seem clear and good to me, well-separated into independent commits, with thorough testing, so I'm hoping it will be merged — especially since this is important stuff. Everyday users of Metals will notice these improvements; this is high-value work (once carried through in the Metals repo).

@dwijnand dwijnand merged commit d490d13 into scala:main Aug 22, 2024
28 checks passed
@dwijnand dwijnand deleted the infer-expected-type branch August 22, 2024 16:46
WojciechMazur added a commit that referenced this pull request Aug 28, 2024
#21496)

Backports #21390 to the 3.5.2 branch.

PR submitted by the release tooling.
[skip ci]
@WojciechMazur WojciechMazur added this to the 3.5.2 milestone Oct 8, 2024
WojciechMazur added a commit that referenced this pull request Dec 4, 2024
…22108)

Backports #21390 to the 3.3.5.

PR submitted by the release tooling.
[skip ci]
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.

6 participants