Error reported at OffsetPosition in the presentation compiler

[scabug]

The presentation compiler reports the type-mismatch error at an offset position, causing the error annotation in the IDE to be just one character.

For example,

  val foo: List[Int] = List(1).map(_.toString)

Will issue the error at the application of map, using an offset position.

The alternative is to parse around that point in the IDE, but the proper solution would be to use a range position.

I investigated a bit and here's what I found:

• the tree position is already an offset position at the point where the error is issued
• the offset position is related to filled-in implicits. The following code shows the same positioning (though simpler example, with type parameters or not, position the error at a range)

  def bar(x: Int)(implicit imp: Int) = x
  
  implicit val impimp = 42  
  val sss: String = bar(1)

See also PR 759

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8807?orig=1
Reporter: @dragos
Affected Versions: 2.11.2

[scabug]

@dragos said:
Further info: the typer has a second try at finding implicits, and uses duplicated trees. It looks like the duplicator focuses positions, and @xeno-by might know more about it. In 75b44a6 a new duplicateAndKeepPositions method is added, but the typer doesn't use it in this case. Could that be it?

[scabug]

@xeno-by said:
duplicateAndKeepPositions was introduced specifically for macros, and back then I didn't even realize that it could be of use elsewhere. However, this seems to be a perfect use case for it as well. What do you think, Jason?

[scabug]

@retronym said (edited on Aug 25, 2014 12:22:20 AM UTC):
Focussing positions during duplication is the right approach when the input tree and the duplicate tree can both end up in the output tree (e.g. see Namers#addDefaultGetters). But if the duplication is done just to be able to do some exploratory typing in order to either a) safely discard an erroneous result and continue with the input tree, or b) use a successful result and discard the input tree, duplicateAndKeepPositions sounds like it ought to work.

[scabug]

@dragos said:
Or maybe the right approach is to focus positions explicitly, depending on the use case? Could there be a cases where you should report errors during a run that normally focuses positions (like addDefaultGetters), and in that case errors will again be focused?

[scabug]

@dragos said:
This is very visible and unfortunately quite common, given how most collection methods take an implicit CBF. It would be great to reach some conclusion, and maybe a fix, if it's not too hard.