-Xsource:2.10 coverage #8402

scabug · 2014-03-12T16:35:17Z

It's hard to know how many more places -Xsource 2.10 might need to be respected for what I want to work, because compilation tends to halt before one has a clear picture. But there are at least the two shown here. First:

class Foo[+CC[X]] { type Coll = CC[_] }

That compiles in 2.10 but not in 2.11.

"What I want to work" is to be able to compile the 2.10 sources with 2.11. For y'all to push through the errors seems like an easy way to find some of the holes in -Xsource.

The other place, which arises first:

/l/trunk1/src/compiler/scala/tools/nsc/backend/icode/Printers.scala:19: error: reference to Linearizer is ambiguous;
it is both defined in trait Linearizers and imported subsequently by
import global.icodes._
  class TextPrinter(writer: PrintWriter, lin: Linearizer) {
                                              ^
one error found
onExit 1

It only became possible to even try this after 0fbd4422b2 which fixed "scala.reflect.internal.FatalError: class Universe does not have a member Quasiquote", thanks for that.

In case you want to pursue this I made a script to embody what I think should work, which might even serve as the basis of a test.

#!/usr/bin/env bash
#
# Run one version of scala compiling against a different one.
#
# Sample usage:
# find /path/to/scala-2.10/src/{asm,library,reflect,compiler} -name '*.scala' -o -name '*.java' | egrep -v '/ant/') | \
#   runner.sh -verbose

runlib=/scala/trunk/build/pack/lib
otherlib=/scala/inst/210/lib

java -Xmx2g \
  -cp "$runlib"/'*' scala.tools.nsc.Main \
  -cp "$otherlib"/'*' \
  -Xsource:2.10 \
  "$@"

scabug · 2014-03-12T16:35:17Z

Imported From: https://issues.scala-lang.org/browse/SI-8402?orig=1
Reporter: @paulp
See #8403, #8265

scabug · 2014-03-12T16:36:41Z

@paulp said:
I did notice some issues have already been flushed out, e.g. this doesn't compile without the -Xsource:2.10 because of the implicit conversion of Null.

% pscalac -Xsource:2.10 /l/trunk1/src/library/scala/Option.scala

scabug · 2014-03-12T16:48:23Z

@paulp said:
For reference the variance soundness fix was in a419799f87 . Also I noticed retronym considering maybe it's not so bad to fix scalaz re: scala/scala#3178 re that subsequent variance soundness fix. I'm going to assume everyone agrees it's worlds better for migration if people can compile their 2.10 sources as-is with -Xsource:2.10. I think that github comment thread predates the realization that -Xsource:2.10 was a really good idea.

scabug · 2014-03-12T17:02:32Z

@retronym said:
I think the first part of the request dups #8265.

BTW, [~garillot] has a jenkins job that typechecks a few projects with -Xsource:2.10. https://jenkins.scala-ide.org:8496/jenkins/view/Scala%20Xsource%20flag%20nightlies/

We know that we don't have the resources to be completely bug-compatible with 2.10 under this flag, so we are relying on the data from these builds to figure out where we get the most bang for our buck.

The primary use case for this flag is to use the 2.11 IDE for 2.10 code bases.

scabug · 2014-03-12T17:03:53Z

@retronym said:
See also scala/scala#3359, which backported the variance compliance to 2.10.x.

scabug · 2014-03-12T17:10:25Z

@paulp said:
Yes I figured some of this would exist in other tickets. Well if it helps rest assured that #8265 will hit many projects. The convenience of invisible unsoundness has an accidental allure like few others.

scabug · 2014-03-12T17:11:12Z

@paulp said:
Using the 2.11 IDE on 2.10 code bases is the same use case as mine, except that maybe it gives up more quickly.

scabug · 2014-03-12T17:13:43Z

@paulp said:
I'll wrap the variance check if I can talk you into the ambiguity check (I don't even know what is the origin of that.)

scabug · 2014-03-12T17:20:19Z

@paulp said (edited on Mar 12, 2014 5:21:09 PM UTC):
After I patch past the variance issue there is only one more issue before compilation succeeds. To me that says it's easily worth making this work and testing it.

The last problem is a change in the scala.runtime support java classes, introduced in 265fc6b230 . Now it generates calls to "create" which doesn't exist in the 2.10 sources.

error: scala.reflect.internal.FatalError: object VolatileFloatRef does not have a member create
	at scala.reflect.internal.Definitions$DefinitionsClass.scala$reflect$internal$Definitions$DefinitionsClass$$fatalMissingSymbol(Definitions.scala:1165)
	at scala.reflect.internal.Definitions$DefinitionsClass$$anonfun$getMember$1.apply(Definitions.scala:1188)
	at scala.reflect.internal.Definitions$DefinitionsClass$$anonfun$getMember$1.apply(Definitions.scala:1183)
	at scala.reflect.internal.Symbols$Symbol.orElse(Symbols.scala:2433)
	at scala.reflect.internal.Definitions$DefinitionsClass.getMember(Definitions.scala:1182)
	at scala.reflect.internal.Definitions$DefinitionsClass.getMemberMethod(Definitions.scala:1217)

It's relatively easy to work around by substituting the 2.11 scala/runtime/*.java classes for the 2.10 ones.

scabug · 2014-03-12T17:27:30Z

@retronym said (edited on Mar 12, 2014 5:27:38 PM UTC):
Yeah, the interaction with ScalaRuntime is why this is only really supported until typer phase. Name based patmat has a bunch of new calls there, for example.

I'm happy to accept a patch for the variance loosening for RC2 (scheduled on Friday, I think).

I'll see if I can pin down the ambiguity change.

scabug · 2014-03-12T17:44:12Z

@paulp said:
Maybe I can reorient this ticket toward the future. How about requiring that scala continue to be able to compile the 2.11 release under -Xsource:2.11 ? I'm sure it would be welcome come 2.12.

scabug · 2014-03-12T17:51:49Z

@retronym said:
I've lodged the ambiguity error as #8403. Looks like its a regression after my refactoring of Contexts.

scabug · 2014-03-12T18:02:10Z

@paulp said:
scala/scala#3623

huitseeker · 2017-04-08T01:40:46Z

Should be fixed by scala/scala#3623

scabug assigned huitseeker Apr 7, 2017

This was referenced Apr 7, 2017

Checking for a WeakTypeTag in macro implementation parameters under -Xsource:2.10 #8461

Closed

Put stronger enforcement of single-method-with-defaults rule under Xsource #8537

Closed

huitseeker removed their assignment Apr 8, 2017

huitseeker closed this as completed Apr 8, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

-Xsource:2.10 coverage #8402

-Xsource:2.10 coverage #8402

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

huitseeker commented Apr 8, 2017

-Xsource:2.10 coverage #8402

-Xsource:2.10 coverage #8402

Comments

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

scabug commented Mar 12, 2014

huitseeker commented Apr 8, 2017