--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
but observe that in general new trees arecreated and a type is assigned - is that just a convention or a requirement?
return the same tree.
The way I've understood it in the past, the caller is supposed to always assume a new tree (in other words, use the tree returned by typer, not the one you passed) but the typer might return (and indeed, usually does) return the same tree.
% qbin/scalac -Yclone-trees test/files/pos/t6722.scala test/files/pos/t6722.scala:10: error: erroneous or inaccessible type dyn.foo.bar.baz.get[String] ^ one error found % qbin/scalac -Yclone-trees test/files/pos/t6201.scala test/files/pos/t6201.scala:12: error: type mismatch; found : scala.xml.Elem required: ?{def must: ?} Note that implicit conversions are not applicable because they are ambiguous: both method toFoo1 in class Test of type (s: scala.xml.Elem)Test.this.Foo1 and method toFoo2 in class Test of type (s: scala.xml.Elem)Test.this.Foo2 are possible conversion functions from scala.xml.Elem to ?{def must: ?} def is: Unit = { (<a>{"a"}</a>).must(<a>{"b"}</a>) } ^
As an experiment, I've modified typed to return shallow duplicated trees [1] and let Jenkins have at it [2].
Boy, talk about dizzying.Implicit search appears to be one of the worst culprits. Lots of vanishing views. This comes as no surprise, recalling https://github.com/scala/scala/commit/58bfa19332 .
"usually" here means "if the tree is already typed", right? in case the input is not typed, typer would "usually" (always?) create a copy first, no?
The failures in the Dynamic tests show one root cause, the use of `Tree#==`.
If the typer stops modifying trees in place, reification won't work, because then the originals of type trees won't have symbols any more, and those are essential to reification. Well, on a second thought, we could probably go out of our way and assign symful originals to typetrees produced by typed...
I'm afk, so I can't check unfortunately
On Wed, Mar 6, 2013 at 9:53 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
If the typer stops modifying trees in place, reification won't work, because then the originals of type trees won't have symbols any more, and those are essential to reification. Well, on a second thought, we could probably go out of our way and assign symful originals to typetrees produced by typed...
indeed that sounds more robust - do we have those symful/typed type trees available at the place where they are replaced by a TypeTree?
On Wed, Mar 6, 2013 at 9:56 AM, Lukas Rytz <lukas...@epfl.ch> wrote:On Wed, Mar 6, 2013 at 9:53 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
If the typer stops modifying trees in place, reification won't work, because then the originals of type trees won't have symbols any more, and those are essential to reification. Well, on a second thought, we could probably go out of our way and assign symful originals to typetrees produced by typed...
indeed that sounds more robust - do we have those symful/typed type trees available at the place where they are replaced by a TypeTree?As I found out when I tried this, any code the interrogates Context#tree breaks when typed doesn't operate in place.
Examples over on SI-7176. I discussed this quickly with Martin yesterday, he suggested that certain at points during type checking (e.g typedApply) should add more specific information to the Context, so that places like `adaptToMemberWithArgs` wouldn't need to rely on tree equality.-jason
As I found out when I tried this, any code the interrogates Context#tree breaks when typed doesn't operate in place.But in most of the cases, type checking is NOT in place, right? e.g. Select, _Def, Block, Function, ... we do something liketreeCopy.XYZ(inputTree, newArg1, newArg2).setType(tpe)The fact that the some parts of the compiler rely on in place typing seems also fishy - we don't really know in which cases the same reference is returned, or do we..?
--
Yep I'd be glad to join!
--