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

Improve assertion error message for Apply and TypeApply #18700

Conversation

nicolasstucki
Copy link
Contributor

@nicolasstucki nicolasstucki commented Oct 16, 2023

These are valid prefixes for a TypeApply in the same way they are for an Apply.

See #16861 (comment)

@benhutchison
Copy link
Contributor

@nicolasstucki thank you 🙏

@nicolasstucki nicolasstucki added this to the 3.4.0 milestone Oct 20, 2023
@nicolasstucki nicolasstucki added the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label Oct 20, 2023
@dwijnand
Copy link
Member

@nicolasstucki I fixed the root cause in #18719, and then I'm tweaking that in #18727.

@nicolasstucki nicolasstucki force-pushed the avoid-error-on-type-apply-with-inline-or-hole-prefix branch from 7c7d299 to d2b97e7 Compare October 20, 2023 09:10
@nicolasstucki
Copy link
Contributor Author

@nicolasstucki I fixed the root cause in #18719, and then I'm tweaking that in #18727.

Ok, I changed this PR to only improve the assertion failure message.

@nicolasstucki nicolasstucki changed the title Avoid error on TypeApply with Inline or Hole prefix Improve assertion error message for Apply and TypeApply Oct 20, 2023
@nicolasstucki nicolasstucki requested review from dwijnand and removed request for odersky October 20, 2023 09:15
@nicolasstucki nicolasstucki assigned dwijnand and unassigned odersky Oct 20, 2023
assert(ctx.reporter.errorsReported)
assert(
fn.isInstanceOf[RefTree | GenericApply] || ctx.reporter.errorsReported,
s"Illegal TypeApply function prefix: $fn"
Copy link
Member

Choose a reason for hiding this comment

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

We should use the i interpolator, so it's pretty-printed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No. We need to see the exact AST. Otherwise we would not see the difference between a TypeApply and Inlined; or some similar cases where show is equivalent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another way to see this is as a match error. Maybe I could encode it in a simpler way and make it fail with an equivalently useful output. I will try that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The alternative is

  def TypeApply(fn: Tree, args: List[Tree])(using Context): TypeApply = fn match
    case Block(Nil, expr) =>
      TypeApply(expr, args)
    case _: RefTree | _: GenericApply =>
      ta.assignType(untpd.TypeApply(fn, args), fn, args)
    case _ if ctx.reporter.errorsReported => // We expect the error. Otherwise, we want to throw a match error.
      ta.assignType(untpd.TypeApply(fn, args), fn, args)

But this one does duplicate ta.assignType(untpd.TypeApply(fn, args), fn, args). I find the current one clearer.

Copy link
Member

Choose a reason for hiding this comment

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

How about i"Illegal TypeApply function prefix: $fn (${fn.className})" then? Don't need the verbose nested trees, I would think.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given the history of the failure, I would argue otherwise. Knowing which tree caused the issue in one of those large projects can be helpful in pinpointing the likely source of the problem.

@nicolasstucki nicolasstucki merged commit 9a64c09 into scala:main Oct 20, 2023
18 checks passed
@nicolasstucki nicolasstucki deleted the avoid-error-on-type-apply-with-inline-or-hole-prefix branch October 20, 2023 13:57
WojciechMazur added a commit that referenced this pull request Jun 22, 2024
…" to LTS (#20729)

Backports #18700 to the LTS branch.

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
backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants