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

Type errors should evaluate type matches with known arguments #22333

Open
belamenso opened this issue Jan 10, 2025 · 3 comments · May be fixed by #22337
Open

Type errors should evaluate type matches with known arguments #22333

belamenso opened this issue Jan 10, 2025 · 3 comments · May be fixed by #22337
Assignees
Labels
area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:enhancement

Comments

@belamenso
Copy link

belamenso commented Jan 10, 2025

Compiler version

3.6.2

Minimized example

import scala.Tuple

class Container[Rs <: Tuple] {
  def guard(a: Tuple.Tail[Rs]): Unit = ()
}

@main def main(): Unit =
  Container[(1,2,3)].guard((5, 6, 8))

Output Error message

[error] -- [E007] Type Mismatch Error: Main.scala:8:27 
[error] 8 |  Container[(1,2,3)].guard((5, 6, 8))
[error]   |                           ^^^^^^^^^
[error]   |                   Found:    (Int, Int, Int)
[error]   |                   Required: Tuple.Tail[((1 : Int), (2 : Int), (3 : Int))]
[error]   |
[error]   | longer explanation available when compiling with `-explain`
[error] one error found

Why this Error/Warning was not helpful

The message was unhelpful because it contains unevaluated type matches (Tuple.Tail) that depend on entirely known types.

Suggested improvement

It could look like

[error] 8 |  Container[(1,2,3)].guard((5, 6, 8))
[error]   |                           ^^^^^^^^^
[error]   |                   Found:    (Int, Int, Int)
[error]   |                   Required: ((2 : Int), (3 : Int))
@belamenso belamenso added area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:enhancement stat:needs triage Every issue needs to have an "area" and "itype" label labels Jan 10, 2025
@belamenso belamenso changed the title Type errors when using implicit witnesses should be simplified before reporting Type errors shoud fully evaluate type matches inside Jan 10, 2025
@belamenso belamenso changed the title Type errors shoud fully evaluate type matches inside Type errors should evaluate type matches with known arguments Jan 10, 2025
@Gedochao Gedochao removed the stat:needs triage Every issue needs to have an "area" and "itype" label label Jan 10, 2025
@hamzaremmal hamzaremmal self-assigned this Jan 10, 2025
@belamenso
Copy link
Author

belamenso commented Jan 12, 2025

@hamzaremmal thanks for quick action. I have another closely related bug, but I do not know if it is the same as this one or not. It could be the same cause (where it just does not evaluate the type in the error message) or it could be something else.

Single indirection makes implicitNotFound print the argument name not its value

Dotty version 3.6.2

type IntLike[T] <: Boolean = T match
  case Int => true
@annotation.implicitNotFound("Comparing ${T} to Int")
type IsIntLike[T] = IntLike[T] =:= true
type Indirection[A] = IsIntLike[A] & (true =:= true) // something after & is needed for reproduction
def f[Z](using Indirection[Z]): Unit = ()
@main def main(): Unit = f[Double]

This is supposed to fail to compile, the problem is in the error message. Current error:

[error] -- [E172] Type Error: Main.scala:7:34 
[error] 7 |@main def main(): Unit = f[Double]
[error]   |                                  ^
[error]   |                                  Comparing A to Int
[error] one error found

The custom error message prints A which is the parameter name from Indirection instead of its value Double.

@hamzaremmal
Copy link
Member

@belamenso Can you please open another issue for this second issue.

@belamenso
Copy link
Author

Ok, moved to #22348 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants