compiling sbt with 2.11

[Paul Phillips]

I have nine compilation errors trying to build sbt with 2.11. My suspicion is that they are genuine ambiguities which have recently become errors thanks to scalac becoming more adept at noticing what things are. However the types are too hairy for me to be interested in decoding them far enough to convince myself of that.

Would any sbt hacker like to a) confirm or deny that these should be fixed in sbt, not scalac and b) fix them?

Similar situation which arose with scalaz: https://github.com/scalaz/scalaz/commit/20fc356a27f41

If y

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:142: ambiguous implicit values:

[error]  both method inlineIvyToHL in object L5 of type => sbt.InlineIvyConfiguration => sbt.Types.:+:[sbt.IvyPaths,sbt.Types.:+:[Seq[sbt.Resolver],sbt.Types.:+:[Seq[sbt.Resolver],sbt.Types.:+:[Seq[sbt.ModuleConfiguration],sbt.Types.:+:[Boolean,sbt.Types.:+:[Seq[String],sbt.HNil]]]]]]

[error]  and method moduleConfToHL in object L4 of type => sbt.ModuleConfiguration => sbt.Types.:+:[String,sbt.Types.:+:[String,sbt.Types.:+:[String,sbt.Types.:+:[sbt.Resolver,sbt.HNil]]]]

[error]  match expected type I => J

[error]   implicit def moduleIC: InputCache[ModuleID] = wrapIn

[error]                                                 ^

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:164: ambiguous implicit values:

[error]  both method exclusionToHL in object L2 of type => sbt.ExclusionRule => sbt.Types.:+:[String,sbt.Types.:+:[String,sbt.Types.:+:[String,sbt.Types.:+:[Seq[String],sbt.HNil]]]]

[error]  and method crossToHL in object L2 of type => sbt.CrossVersion => sbt.Types.:+:[Int,sbt.HNil]

[error]  match expected type I => J

[error]   implicit def artifactIC: InputCache[Artifact] = wrapIn

[error]                                                   ^

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:187: ambiguous implicit values:

[error]  both method retrieveToHL in object L1 of type => sbt.RetrieveConfiguration => sbt.Types.:+:[sbt.PlainFileInfo,sbt.Types.:+:[String,sbt.HNil]]

[error]  and method ivyPathsToHL in object L1 of type => sbt.IvyPaths => sbt.Types.:+:[sbt.PlainFileInfo,sbt.Types.:+:[Option[sbt.PlainFileInfo],sbt.HNil]]

[error]  match expected type I => J

[error]   implicit def ivyScalaIC: InputCache[IvyScala] = wrapIn

[error]                                                   ^

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:192: ambiguous implicit values:

[error]  both method configurationToHL in object L1 of type => sbt.Configuration => sbt.Types.:+:[String,sbt.Types.:+:[String,sbt.Types.:+:[Boolean,sbt.Types.:+:[Set[String],sbt.Types.:+:[Boolean,sbt.HNil]]]]]

[error]  and method passwordToHL in object L1 of type => sbt.RepositoryHelpers.PasswordAuthentication => sbt.Types.:+:[Array[Byte],sbt.Types.:+:[Array[Byte],sbt.HNil]]

[error]  match expected type I => J

[error]   implicit def extIvyIC: InputCache[ExternalIvyConfiguration] = wrapIn

[error]                                                                 ^

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:193: ambiguous implicit values:

[error]  both method passwordToHL in object L1 of type => sbt.RepositoryHelpers.PasswordAuthentication => sbt.Types.:+:[Array[Byte],sbt.Types.:+:[Array[Byte],sbt.HNil]]

[error]  and method keyFileToHL in object L1 of type => sbt.RepositoryHelpers.KeyFileAuthentication => sbt.Types.:+:[Array[Byte],sbt.Types.:+:[sbt.HashFileInfo,sbt.Types.:+:[Array[Byte],sbt.HNil]]]

[error]  match expected type I => J

[error]   implicit def confIC: InputCache[Configuration] = wrapIn

[error]                                                    ^

[error] /r/sbt/main/actions/src/main/scala/sbt/CacheIvy.scala:196: diverging implicit expansion for type Equiv[Array[Byte]]

[error] starting with method comparatorToOrdering in trait LowPriorityOrderingImplicits

[error]     unionInputCache[SshAuthentication, PasswordAuthentication :+: KeyFileAuthentication :+: HNil]

[error]                    ^

[error] /r/sbt/main/actions/src/main/scala/sbt/Tests.scala:137: type mismatch;

[error]  found   : Any

[error]  required: Iterable[sbt.TestResult.Value]

[error]         (overall(rs), ms reduce (_ ++ _))

[error]                  ^

[error] /r/sbt/main/actions/src/main/scala/sbt/Tests.scala:137: value reduce is not a member of Any

[error]         (overall(rs), ms reduce (_ ++ _))

[error]                          ^

[error] /r/sbt/main/actions/src/main/scala/sbt/compiler/Eval.scala:222: value isTopLevelModule is not a member of Eval.this.global.Symbol

[error]       case ValDef(_, n, actualTpe, _) if  tree.symbol.owner.isTopLevelModule && types.exists(_ <:< actualTpe.tpe) =>

[error]                                                             ^

[error] 9 errors found

[error] (actions/compile:compile) Compilation failed

[Paul Phillips]

On Fri, Jan 11, 2013 at 4:44 PM, Paul Phillips <pa...@improving.org> wrote:

If y

Looks like network flailing robbed me of that line, which was something like if you use sbt-extras, you should be able to reproduce with:

sbt -v -scala-version 2.11.0-M1 -binary-version 2.10 update compile

[Jason Zaugg]

On Saturday, January 12, 2013 1:44:27 AM UTC+1, Paul Phillips wrote:

I have nine compilation errors trying to build sbt with 2.11. My suspicion is that they are genuine ambiguities which have recently become errors thanks to scalac becoming more adept at noticing what things are. However the types are too hairy for me to be interested in decoding them far enough to convince myself of that.

Would any sbt hacker like to a) confirm or deny that these should be fixed in sbt, not scalac and b) fix them?

I believe that culpability is shared. Here's what I know so far:

 - bdab9cd5 / PR 1631, "Lower confusion levels in typedApply" flipped this from crashing with "In no progress in completing object Tests:<?>" to the current behaviour.

 - The errors reported in Tests.scala are _only_ reported after a particular error is issued in CacheIvy.scala. Compile it by itself, or with CacheIvy.scala cleared of errors, and the correct types are inferred. Scary.

 - the presence of implicits for Equiv[Map[String, String]], Set[String], ... in CacheIvy seems to be a problem -- they are ambiguous with those imported from Ordering._. But they were also ambiguous in 2.9.2. I had expected the problem was due to my fix for SI-6667 "Abort after any ambiguous in-scope implicit", but that theory doesn't fit with my bisection so far.

-jason

[Jason Zaugg]

I went back further the predate the "no progress in completing" crasher, and landed at the regression [1]. Looks like that unused val `checked` really should have remained unused. (I'm waiting on a build to confirm this, but it seems like a lock.)

I've lodged an issue [2], and will try to craft a test case to go with the fix.

-jason

[1] https://github.com/paulp/scala/commit/9c09c17#L50L671

[2] https://issues.scala-lang.org/browse/SI-6966

[Paul Phillips]

Ha, I assume you say the comment which I removed along with that substitution:

  // TODO: the return tree is ignored.  This seems to make
  // no difference, but it's bad practice regardless.

There's something about actually writing down "this seems to make no difference" which guarantees future excitement.

Of course, it's even worse practice if the return tree from typed can't be used but the original can.

[Mark Harrah]

On Sat, 12 Jan 2013 06:42:45 -0800 (PST)
Jason Zaugg <jza...@gmail.com> wrote:

> On Saturday, January 12, 2013 1:44:27 AM UTC+1, Paul Phillips wrote:
>
> > I have nine compilation errors trying to build sbt with 2.11. My suspicion
> > is that they are genuine ambiguities which have recently become errors
> > thanks to scalac becoming more adept at noticing what things are. However
> > the types are too hairy for me to be interested in decoding them far enough
> > to convince myself of that.
> >
> > Would any sbt hacker like to a) confirm or deny that these should be fixed
> > in sbt, not scalac and b) fix them?

The last error might be valid. I'll have to see if isTopLevelModule was removed.

> I believe that culpability is shared. Here's what I know so far:
>
> - bdab9cd5 / PR 1631, "Lower confusion levels in typedApply" flipped this
> from crashing with "In no progress in completing object Tests:<?>" to the
> current behaviour.
> - The errors reported in Tests.scala are _only_ reported after a
> particular error is issued in CacheIvy.scala. Compile it by itself, or with
> CacheIvy.scala cleared of errors, and the correct types are inferred. Scary.

Yes, we saw this when moving to 2.10.0 as well and Eugene V. just worked around it.

I believe the cause that time was the new behavior where an implicit parameter was no longer given priority over other implicits in scope. This was recently discussed in the eight billionth part of implicit resolution thread.

> - the presence of implicits for Equiv[Map[String, String]], Set[String],
> ... in CacheIvy seems to be a problem -- they are ambiguous with those
> imported from Ordering._. But they were also ambiguous in 2.9.2. I had
> expected the problem was due to my fix for SI-6667 "Abort after any
> ambiguous in-scope implicit", but that theory doesn't fit with my bisection
> so far.

CacheIvy.scala was an attempt to semi-automatically derive instances of the InputCache typeclass by only specifying the conversion of a type to an hlist. It is very sensitive to implicit resolution changes and bugs, though. I'll be happy to get rid of it, but it has never been quite enough of a problem to figure out a replacement.

-Mark

> -jason
>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/hFskSeOYXMkJ.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>

[Paul Phillips]

On Sat, Jan 12, 2013 at 6:42 AM, Jason Zaugg <jza...@gmail.com> wrote:

 - The errors reported in Tests.scala are _only_ reported after a particular error is issued in CacheIvy.scala. Compile it by itself, or with CacheIvy.scala cleared of errors, and the correct types are inferred. Scary.

If you are riding high on your current success levels and would like to continue investigations, a possible contributor to this kind of non-determinism are calls to normalize. (I realize that your finding with "checked" may be enough to explain this batch, but since I'm thinking of it.) Especially, if a typing cycle is encountered under one set of conditions but not another similar set of conditions, it could easily be a call to normalize which makes the difference.

I replaced a lot of them with calls to dealias/dealiasWiden and I expect to replace most of the rest before I'm through. There are a couple in Definitions which are particularly egregious, and which have the stomach-punch-like tendency to help -Ydebug and type printing in general to alter compiler behavior. Those at least are fixed in a shortly pending pull request.