The dealiasWiden pullrequest bumps complexities of certain types
32 views
Skip to first unread message
Eugene Burmako
Feb 23, 2013, 6:39:32 AM2/23/13
to scala-internals
https://gist.github.com/xeno-by/5019439
This sometimes changes the outcome of `ImplicitSearch.dominates`,
turning previously successful implicit searches into divergent errors.
Are we cool with this?
This sometimes changes the outcome of `ImplicitSearch.dominates`,
turning previously successful implicit searches into divergent errors.
Are we cool with this?
Jason Zaugg
Feb 23, 2013, 7:38:05 AM2/23/13
to scala-i...@googlegroups.com
Looks like that part wasn't backported to 2.10.1, but just to be sure, could you run your test against the 2.10.1 branch?
But even for master, we should rework that method to give the same complexities as before. Perhaps in the process of writing some tests around this we'll find an inconsistency that warrants a change, but that should be justified.
-jason
Paul Phillips
Feb 23, 2013, 9:05:57 AM2/23/13
to scala-i...@googlegroups.com
On Sat, Feb 23, 2013 at 3:39 AM, Eugene Burmako <eugene....@epfl.ch> wrote:
This sometimes changes the outcome of `ImplicitSearch.dominates`,
turning previously successful implicit searches into divergent errors.
Are we cool with this?
tp = java.lang.type, tp.normalize = ThisType(java.lang)
tp = java.lang.type, tp.dealiasWiden = TypeRef(ThisType(java), java.lang, List())
So dealiasWiden unrolls the packages one at a time, and normalize stops all at once on ThisType(java.lang). We should work out whether there is some useful distinction to these multiple representations, but in the meantime, I'd say complexity should terminate whenever it encounters a package in whatever representation.
Eugene Burmako
Feb 23, 2013, 9:33:44 AM2/23/13
to scala-internals
I've minimized the test case here:
https://github.com/scalamacros/kepler/commit/3e7089ee2be5d663e4256be3b8c331e5b7965895.
2.10.x is affected. Will check 2.10.1 within a couple hours.
On Feb 23, 1:38 pm, Jason Zaugg <jza...@gmail.com> wrote:
https://github.com/scalamacros/kepler/commit/3e7089ee2be5d663e4256be3b8c331e5b7965895.
2.10.x is affected. Will check 2.10.1 within a couple hours.
On Feb 23, 1:38 pm, Jason Zaugg <jza...@gmail.com> wrote:
Eugene Burmako
Feb 23, 2013, 9:37:10 AM2/23/13
to scala-internals
My bad. The test only works for master, because in 2.10.x implicit
macros are broken w.r.t type inference. Therefore, the status of both
2.10.1 and 2.10.x is inconclusive. I'll take a another look soon, but
now I have to run.
On Feb 23, 3:33 pm, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> I've minimized the test case here:https://github.com/scalamacros/kepler/commit/3e7089ee2be5d663e4256be3....
macros are broken w.r.t type inference. Therefore, the status of both
2.10.1 and 2.10.x is inconclusive. I'll take a another look soon, but
now I have to run.
On Feb 23, 3:33 pm, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
> I've minimized the test case here:https://github.com/scalamacros/kepler/commit/3e7089ee2be5d663e4256be3....
Eugene Burmako
Feb 23, 2013, 11:30:13 AM2/23/13
to scala-internals
It looks like 2.10.x is okay. It still uses normalize.
Eugene Burmako
Feb 24, 2013, 4:30:51 AM2/24/13
to scala-internals
Wrt multiple possible representations for package types, I just
remembered this thing:
https://github.com/scalamacros/kepler/blob/ef24a8b53c8ee88269c2f14a694550f6d99a1545/src/reflect/scala/reflect/internal/Types.scala#L295
On Feb 23, 3:05 pm, Paul Phillips <pa...@improving.org> wrote:
remembered this thing:
https://github.com/scalamacros/kepler/blob/ef24a8b53c8ee88269c2f14a694550f6d99a1545/src/reflect/scala/reflect/internal/Types.scala#L295
On Feb 23, 3:05 pm, Paul Phillips <pa...@improving.org> wrote:
Reply all
Reply to author
Forward
0 new messages