Interactive scaladoc: demand new typer run when done.#2387
Interactive scaladoc: demand new typer run when done.#2387adriaanm merged 1 commit intoscala:2.10.xfrom vigdorchik:interactive_scaladoc
Conversation
|
We'll also take reviews from @huitseeker |
There was a problem hiding this comment.
Have you consider something like
fragments.groupBy(_._2).map(
(sfile,symbls) => "%s in %s".format(symbls.map(_._1), sfile)
).join(", ")to avoid logfile clutter ?
There was a problem hiding this comment.
I agree fragments logging would be too much of a clutter. Given that symbol -> source file mapping is almost 1:1 in stdlib, I think I'd better remove this info at all.
|
I don't include the test here,however I see test failures disappear on the IDE side. The caches are dropped on a new run, so this change fixes the problem. |
There was a problem hiding this comment.
[nitpicking]
Have you considered something like
fragments.groupBy(_._2).map(
(sfile,symbls) => "%s in %s".format(symbls.map(_._1), sfile)
).join(", ")
to avoid logfile clutter ?
[/nitpicking]
There was a problem hiding this comment.
Unfortunately that would still be too much: as symbols mostly come from different SourceFiles grouping is not benefitial.
|
While it's true I see less spurious chokage in the IDE thanks to this, I'm afraid this has a performance price in interactive situations. For that reason and maintenance purposes, I'd love to see a code comment at the |
As of now, when backgroundCompile is in the same typer run as scaladoc-fetching logic, typer is confused with stale symbols.
|
@huitseeker done adding the comment. |
Interactive scaladoc: demand new typer run when done.
As of now, when further backgroundCompile is in the same typer run as
scaladoc-fetching logic, it gets confused with stale symbols.
Please check if there are other inconsistencies in this PC method.
Review by @odersky.