Apparently, the invariant, that point is in range, is not enforced.

I expected start <= point < end, but "zero extent" ranges are typical, also in dotty spans.

Splitting this commit into the pos fix for interpolator (plus gratuitous refactoring), then the tweak that you can request a spanning pos to include your default.point; otherwise a default.point out of range is ignored.

The tweaks improve point positioning, but as noted on the ancient PR for NamesDefault, it's difficult to code defensively because it's easy to accidentally derive a range via offsetpos.withStart. This PR is not ambitious because of likely interactions with tooling.

For example, NamePos gives the wrong position to a var x under -Yrangepos:false. Perhaps the option to turn off range positioning should be deprecated.

At any phase.

[info] [info] welcome to sbt 1.9.9 (Oracle Corporation Java 1.8.0_332)
[info] [info] loading project definition from /tmp/sbt_612ad334/project
[info] [info] loading settings for project sbt_612ad334 from common.sbt ...
[info] [info] set current project to sbt_612ad334 (in build file:/tmp/sbt_612ad334/)
[info] [info] compiling 2 Scala sources to /tmp/sbt_612ad334/target/classes ...
[info] [error] ## Exception when compiling 2 sources to /tmp/sbt_612ad334/target/classes
[info] [error] java.lang.NoClassDefFoundError: scala/collection/Seq$
[info] [error] scala.reflect.internal.Definitions$DefinitionsClass.Collection_SeqModule$lzycompute(Definitions.scala:507)
[info] [error] scala.reflect.internal.Definitions$DefinitionsClass.Collection_SeqModule(Definitions.scala:507)
[info] [error] scala.reflect.internal.Definitions$DefinitionsClass$RunDefinitions.Seq_apply$lzycompute(Definitions.scala:1735)
[info] [error] scala.reflect.internal.Definitions$DefinitionsClass$RunDefinitions.Seq_apply(Definitions.scala:1733)
[info] [error] scala.reflect.internal.Definitions$DefinitionsClass$RunDefinitions.isSeqApply(Definitions.scala:1762)
[info] [error] scala.tools.nsc.transform.CleanUp$CleanUpTransformer.transformApply(CleanUp.scala:558)
[info] [error] scala.tools.nsc.transform.CleanUp$CleanUpTransformer.transform(CleanUp.scala:726)
[info] [error] scala.tools.nsc.transform.CleanUp$CleanUpTransformer.transform(CleanUp.scala:37)

/rebuild

Maybe it's time to follow Scala 3 and underline the range instead of the finicky point.

The failure on the first commit was weird.

[info] [info] compiling 1 Scala source to /tmp/sbt_8d42cfbb/target/classes ...
[info] [error] ## Exception when compiling 1 sources to /tmp/sbt_8d42cfbb/target/classes
[info] [error] java.util.ServiceConfigurationError: xsbti.compile.CompilerInterface2: jar:file:/home/jenkins/.ivy2/local/org.scala-lang/scala2-sbt-bridge/2.13.15-bin-SNAPSHOT/jars/scala2-sbt-bridge.jar!/META-INF/services/xsbti.compile.CompilerInterface2:1: Illegal provider-class name: 6scala.tools.xsbt.CompilerBridge

The failure on the last commit was the new check file from #10792

The checks were green before rebasing.

Looks all good to me, thank you!

The change to WrappingPosAccumulator is a bit hard to asses. Did you maybe add some assertions to find call sites of wrappingPos / code examples where the default.point falls outside the wrapping range?

I intend to improve the code comment on widening pos. I believe I did start by asserting that point was in range.

I haven't looked at this again yet, but "For warnings" fails the test for positions of

val x, y = 42

where x overlaps with y, so x is focused on the x.

I didn't touch positions in that PR, but I see this touches mkClosure. Retronym's fix that induces focus was to supply the position of the rhs 42. Maybe my rhs is no longer a range, so x no longer overlaps, so x is not focused (on my other PR).

It's by a pernicious coincidence that I must refresh my memory on positions, so it might be opportune to refresh this PR.

Edit: morning after, it was just a cut/paste error.

rebased on "for warnings".

let me know when it's ready for another 👀

I was just looking for a new adventure in rebasing. Maybe I can figure out what to cherry-pick.

Not sure about the history of the semantics of position operations, but I see these tweaks are coping with withStart always producing a range but withPoint returning either a range or moving an offset position.

Symbolic ops seem to suggest notation, x ^| y for "which point do you prefer", etc, but the promise of convenience is not realized. Scala 2 is burdened with offset positions. Imagine if in 2014 the effort was to replace positions with spans on scala 2.