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

Cannot print types with wildcards #629

Closed
tindzk opened this issue Jun 12, 2017 · 6 comments · Fixed by com-lihaoyi/PPrint#72
Closed

Cannot print types with wildcards #629

tindzk opened this issue Jun 12, 2017 · 6 comments · Fixed by com-lihaoyi/PPrint#72

Comments

@tindzk
Copy link

tindzk commented Jun 12, 2017

If a type with parameter bounds is instantiated with a wildcard, it cannot be printed:

@ case class MyList[T <: String]() 
defined class MyList
@ null.asInstanceOf[MyList[_]] 
cmd3.sc:8: type arguments [_$1] do not conform to class MyList's type parameter bounds [T <: String]
            .print(res3, res3, "res3", _root_.scala.None)                                                                                                                                                                        
             ^                                                                                                                                                                                                                   
cmd3.sc:8: type arguments [_$1] do not conform to class MyList's type parameter bounds [T <: String]
            .print(res3, res3, "res3", _root_.scala.None)                                                                                                                                                                        
                  ^                                                                                                                                                                                                              
Compilation Failed

The same example works fine in Typelevel's REPL.

See also typelevel/scala#156.

@lihaoyi
Copy link
Member

lihaoyi commented Jun 12, 2017

Huh I thought this would have been caught by now; I guess we missed a spot

@lihaoyi
Copy link
Member

lihaoyi commented Jun 14, 2017

This is a problem with PPrint. Here is a minimal repro without Ammonite:

scala> case class MyList[T <: String]()
defined class MyList

scala> println(pprint.TPrint.default[MyList[_]])
<console>:14: error: type arguments [_$1] do not conform to class MyList's type parameter bounds [T <: String]
       println(pprint.TPrint.default[MyList[_]])
                                    ^

Spent some time digging into this, didn't manage to get a satisfactory answer why this is happening. The implicit-recursion makes things kinda confusing in the TPrint macro expansion, maybe we could make it not-recurse in the case of _? That might make the problem go away, or at the very least make it easier to debug

@tindzk
Copy link
Author

tindzk commented Jun 15, 2017

If default takes a type parameter, this most likely triggers the issue I've described. Consider the following function:

def f[T](value: T): Unit = {}

Passing a MyList[_] value to f() is not allowed in regular Scala. If you change the parameter type to Any, it compiles. I am actually curious to learn about the motivation behind this Scala design decision.

@lihaoyi
Copy link
Member

lihaoyi commented Jun 15, 2017

@tindzk not sure what you are referring to, but passing a MyList[_] to f in your example works just fine.

@  case class MyList[T <: String]()
defined class MyList
@ def f[T](value: T): Unit = {}
defined function f
@ f[MyList[_]](???)
scala.NotImplementedError: an implementation is missing
  scala.Predef$.$qmark$qmark$qmark(Predef.scala:284)
  ammonite.$sess.cmd2$.<init>(cmd2.sc:1)
  ammonite.$sess.cmd2$.<clinit>(cmd2.sc)

This is a bug in the pprint.TPrint module, not in Scala itself

@tindzk
Copy link
Author

tindzk commented Jun 15, 2017

This is what I had in mind:

scala> f(null.asInstanceOf[MyList[_]])
<console>:15: error: type arguments [_$1] do not conform to class MyList's type parameter bounds [T <: String]
       f(null.asInstanceOf[MyList[_]])

@lihaoyi
Copy link
Member

lihaoyi commented Jun 15, 2017

huh, interesting. Maybe raise an issue on scala/scala? That definitely should work.

EDIT: Notably, giving an explicit type param for f makes it work, so it seems type-inference is screwing up

scala> case class MyList[T <: String]()
defined class MyList

scala> null.asInstanceOf[MyList[_]]
res0: MyList[_] = null

scala> def f[T](value: T): Unit = {}
f: [T](value: T)Unit

scala> f(null.asInstanceOf[MyList[_]])
<console>:15: error: type arguments [_$1] do not conform to class MyList's type parameter bounds [T <: String]
       f(null.asInstanceOf[MyList[_]])
       ^

scala> f[MyList[_]](null.asInstanceOf[MyList[_]])

scala> 

lihaoyi added a commit to com-lihaoyi/PPrint that referenced this issue Dec 6, 2021
Fixes com-lihaoyi/Ammonite#221 
Fixes com-lihaoyi/Ammonite#629 
Fixes com-lihaoyi/Ammonite#670 
Fixes #45 
Fixes #44

The old TPrint implementation did a clever thing where it allowed a user to over-ride the TPrinting of a given type by providing an appropriate implicit. While that worked in most cases, it was fiendishly complex, and the intricate nesting of implicit resolution and macro resolution ended up providing and endless source of hard to resolve bugs.

This new implementation is much simpler and less flexible: we simply walk the type data structure in the macro, and spit out a colored `fansi.Str` with the type names hard-coded to `fansi.Green`. The only runtime support necessary is in the `def recolor` function, which parses the incoming `fansi.Str` and replaces the hardcoded `fansi.Green` colors with whatever is specified by the implicit `TPrintColors`. As implicits cannot be used to override tprinting anymore, we now have hardcoded support for tprinting functions and tuples.

While the old macro generated a complex tree of Scala function calls that is evaluated to generate the output `fansi.Str` at runtime, the new macro simply spits out a single `fansi.Str` that is serialized into a `java.lang.String` and deserialized back into a `fansi.Str` for usage at runtime. We propagate a `WrapType` enumeration up the recursion, to help the callers decide if they need to wrap things in parens or not.

This gives up a bit of flexibility, but AFAIK nobody was really using that flexibility anyway. In exchange, we fix a whole bunch of long-standing bugs, and have a drastically simpler implementation.

The fixed bugs are covered by regression unit tests added to `TPrintTests.scala`. All existing tests also pass, so hopefully that'll catch any potential regressions. There's probably more bugs where we're not properly setting or handling the `WrapType`, but exhaustively testing/surfacing/fixing all of those is beyond the scope of this PR. For now, I just kept the current set of tests passing.

Managed to get the Scala3 side working. I didn't realize how half-baked the Scala3 implementation of TPrint is; so much of the Scala2 functionality just isn't implemented and doesn't work. Nevertheless, fixing that is beyond the scope of this PR. I just kept it green with the existing set of green tests passing (except for the custom tprinter test, which is no longer applicable)

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

Successfully merging a pull request may close this issue.

2 participants