From ed743265173e4dcbd5a77ffb6364bff1d587c90e Mon Sep 17 00:00:00 2001 From: Grzegorz Kossakowski Date: Fri, 7 Mar 2014 14:28:47 +0100 Subject: SI-8372: unspliceable type printed in error message The b8a76f688c6ce2a4c305da064303bb46b53be875 introduced ArrayOps.{unzip, unzip3} methods. Both of those methods have ClassTags as context bounds on their type parameters so they can create (and return) instances of Arrays. The type inference for those methods is supposed to be guided by implicit evidence that T <: (T1, T2) (or T <: (T1, T2, T3) in unzip3 case). However, context bounds are desugared into implicit parameters that prepended in front of implicit parameters declared in source code. That means the implicit evidence won't have a chance to guide type inference because it comes as last implicit parameter. This commit desugars context bounds and puts them at the end of implicit parameter list. This way type inference is guided properly and we get expected compiler errors for missing class tags. The change to parameters order breaks binary compatibility with respect to 2.11.0-RC1. I added filters to our binary compatibility configuration files. We can get rid of them as soon as 2.11.0 is out. --- test/files/neg/t8372.check | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'test/files/neg') diff --git a/test/files/neg/t8372.check b/test/files/neg/t8372.check index 87c27a26cc..6a6424a834 100644 --- a/test/files/neg/t8372.check +++ b/test/files/neg/t8372.check @@ -1,7 +1,7 @@ -t8372.scala:7: error: tpe T1 is an unresolved spliceable type +t8372.scala:7: error: No ClassTag available for T1 def unzip[T1, T2](a: Array[(T1, T2)]) = a.unzip ^ -t8372.scala:9: error: tpe T1 is an unresolved spliceable type +t8372.scala:9: error: No ClassTag available for T1 def unzip3[T1, T2, T3](a: Array[(T1, T2, T3)]): (Array[T1], Array[T2], Array[T3]) = a.unzip3 ^ two errors found -- cgit v1.2.3