Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ambiguity in first phase of implicit argument search prevents second phase unless the method call has an expected type #6667

Closed
scabug opened this issue Nov 14, 2012 · 11 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Nov 14, 2012

class C 
object C {
  implicit def companion = new C
}

object Test {
  implicit val inScope1, inScope2 = new C
  implicitly[C]: Unit // C.companion used.
  implicitly[C]       // ambiguity reported, rather than falling back to C.companion
}

See:

// Typers.scala
if (original != EmptyTree && pt != WildcardType)
  typer1.silent(tpr => {
    val withImplicitArgs = tpr.applyImplicitArgs(tree)
    if (tpr.context.hasErrors) tree // silent will wrap it in SilentTypeError anyway
    else tpr.typed(withImplicitArgs, mode, pt)
  }) match {
    case SilentResultValue(result) =>
      result
    case _ =>
      debuglog("fallback on implicits: " + tree + "/" + resetAllAttrs(original))
      val tree1 = typed(resetAllAttrs(original), mode, WildcardType)
      tree1.tpe = addAnnotations(tree1, tree1.tpe)
      if (tree1.isEmpty) tree1 else adapt(tree1, mode, pt, EmptyTree)
  }
else
  typer1.typed(typer1.applyImplicitArgs(tree), mode, pt)
@scabug
Copy link
Author

scabug commented Nov 14, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6667?orig=1
Reporter: @retronym
Affected Versions: 2.10.0-RC2
See #6668

@scabug
Copy link
Author

scabug commented Nov 14, 2012

@dcsobral said:
The problem originally reported did not need a companion relation between class and object.

@scabug
Copy link
Author

scabug commented Nov 14, 2012

@retronym said:
It did in a roundabout way; the companion/package objects of enclosing types of a class are actually part of the implicit scope.

But, we'll test both in the fix for this bug.

object Test {
  abstract class Box {
    val value: Int
  }

  implicit val a: Box = new Box {
    val value= 1
  }

  def main(args: Array[String]) {
    implicit val b: Box= new Box {
      val value= 2
    }

    new Object {
      new Test()
    }
    // compare with:
    // new Test()
  }
}

@scabug
Copy link
Author

scabug commented Nov 15, 2012

@dcsobral said:
That still has a companion. I've tested this at work:

class Test()(implicit x: Bop.Box) {
  println(x.value)
}

object Bop {
  abstract class Box {
    val value: Int
  }

  implicit val a: Box = new Box {
    val value= 1
  }

  def main(args: Array[String]) {
    implicit val b: Box= new Box {
      val value= 2
    }

    new Object {
      new Test()
    }
    // compare with:
    // new Test()
  }
}

@scabug
Copy link
Author

scabug commented Nov 15, 2012

@retronym said:
See the comments in #6668 for a discussion about the incongruence between the spec and implementation.

@scabug
Copy link
Author

scabug commented Nov 15, 2012

@retronym said:
@daniel: in your example, the implicit scope of Box includes members in the companion object of it's enclosing type, Bop. It doesn't matter where Test is defined.

@scabug
Copy link
Author

scabug commented Nov 15, 2012

@paulp said:
If it's any consolation daniel, I'm even worse at this.

@scabug
Copy link
Author

scabug commented Nov 21, 2012

@retronym said:
Martin agrees that ambiguity errors in the in-scope implicit search should always prevent the implicits-of-expected-type search. I'll prepare a patch to that effect.

@scabug
Copy link
Author

scabug commented Nov 22, 2012

@retronym said:
scala/scala#1659

@scabug
Copy link
Author

scabug commented Nov 26, 2012

@retronym said:
scala/scala#1675

@scabug scabug closed this as completed Dec 10, 2012
@scabug
Copy link
Author

scabug commented Feb 4, 2013

@retronym said:
Demoting to a lint warning in 2.10.1, still an error in 2.11.0: scala/scala#2063

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants