**Problem**
Nested macro that expands to map or mapN fails to
find the qual because the trees end up being different
between the record scan and actual replacement.
**Solution**
First try for equals normally, then compare the show strings.
**Problem**
Compiler options for the compiler plugins ends up capturing the absolute path, specific to the machine.
**Solution**
This encodes the plugin paths as virtual paths.
**Problem**
Incremental test (aka testQuick) has a bug when companion objects
depends on others since at some point it's failing to look up relationship from Zinc analysis.
**Solution**
This fixes the lookup.
**Problem**
`run` task has been emulated via function call inside of a sandboxed classloader,
and blocking the command processing of sbt server loop.
This poses isolation and availability issues.
**Solution**
This implements client-side run where the server creates a sandbox environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
The client-side behavior has been implemented in sbtn side already.
**Problem**
WHen portfile is not found, sbtn will try to start the server
even when the desired command is shutdown.
**Solution**
When the command is just shutdown, don't start the server.
**Problem**
When compilation fails, it's retrying 10 times
since Retry now retries on non-IOExceptions.
**Solution**
This adds CompileFailed to excluded exception list.
**Problem**
client-side run apparently won't work for Scala.JS,
so forcing sbtn users to client-side run will break the Scala.JS users.
**Solution**
This reverts the client-side run on sbt 1.x, while retaining the
mechanism for sbt 2.x usages via sbtn.
Now, if `run / connectInput := true` is true, stdout will not display on sbtn.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
When ForkOptions outputStrategy is None, Run code currently
tries to use LoggedOutput, which buffers the output when
connectInput is true, which effectively breaks the experience.
**Solution**
This stops falling back to LoggedOutput when connectInput is true.