This channge should turn color on by default in ci builds (see
https://github.com/sbt/sbt/issues/5269). It can still be disabled with
-Dsbt.color=false.
Disabling virtual io prevents the thin client from working. It is
possible that a user may manually start a server with -Dsbt.color=false
but still want to connect a thin client.
Running sbt with -Dsbt.supershell=true and -Dsbt.color=true doesn't work
well because the isAnsiSupported flag is set to false when
-Dsbt.color=false. This causes the processing that ensures that
supershell lines do not get interleaved with normal log lines to be
skipped. To fix this, we can enable ansi codes when supershell is
explicitly enabled.
The ConsoleAppender formatEnabledInEnv field was being used both as an
indicator that ansi codes were supported and that color codes are
enabled. There are cases in which general ansi codes are not supported
but color codes are and these use cases need to be handled separately.
To make things more explicit, this commit adds isColorEnabled and
isAnsiSupported to the Terminal companion object so that we can be more
specific about what the requirements are (general ansi escape codes or
just colors). There are a few cases in ConsoleAppender itself where
formatEnabledInEnv was used to set flags for both color and ansi codes.
When that is the case, we use Terminal.isAnsiSupported because when that
is true, colors should at least work but there are terminals that
support color but not general ansi escape codes.
It is currently the case that all tagged log messages going through a
ConsoleAppender have color codes added and then subsequently stripped
out. This didn't work well in combination with -Dsbt.color=true and
-Dsbt.ci=true because the -Dsbt.color=true was causing
ConsoleAppender.formatEnabledInEnv to be set to true which caused ansi
codes to be enabled. Travis CI supports color codes but not other ansi
escape sequences (this is also often true of embedded shells like in
intellij or jedit). This commit reworks the ConsoleAppender so that we
only add colors if useFormat is enable dand only add
ClearScreenAfterCursor if ansi codes are supported. It also reworks the
ConsoleAppender.write method so that if useFormat is true but
ansiCodesSupported is false that we only remove the non color related
ansi escape sequences so that colors remain.
In canonical mode, System.in will return -1 for ctrl+d on an empty line.
The result of this behavior was that if a user entered ctrl+d during run
in a task that was reading from System.in, sbt would end up exiting
whenever the task exited. This happened because the WriteableInputStream
would close itself when it read -1 from the input stream, which it
assumed meant that the underlying input stream itself had been closed.
When the jline reader tried to read from the closed
WriteableInputStream, it would throw an exception and if the line reader
was for the console channel, it would be interpreted as the user had
inputted ctrl+d in the sbt shell which is supposed to exit sbt. This
change fixes that behavior so that sbt can continue reading input after
the run task exits.
Below functions pass lintIncludeFilter and lintExcludeFilter to lintUnusedinstead of includeLintKeys and excludeLintKeys respectively.
- sbt.internal.LintUnused#lintUnusedTask
- sbt.internal.LintUnused#lintUnusedFunc
Therefore, in the test, we had better to use lint***Filter instead of ***LintKeys.
Ref https://github.com/scala/bug/issues/12112
Current app transformation macro creates a tree that looks like:
```scala
FullInstance.app[[T0[x]](T0[Int], T0[Int]), Unit](scala.Tuple2(task2, task1), (($p$macro$3: (Int, Int)) => {
<synthetic> val $q$macro$2: Int = $p$macro$3._1;
<synthetic> val $q$macro$1: Int = $p$macro$3._2;
{
($q$macro$1: Int);
($q$macro$2: Int);
()
}
}))(AList.tuple2[Int, Int])
```
Starting Scala 2.12.12 the compiler's "pure expression does nothing" has become more enthusiastic/accurate in its reach, and it started warning about the naked reference to `$q$macro$1` that appears to do nothing, even though in reality it would trigger the tasks and do something in the context of sbt. It's just _that_ particular line ends up macroed away into a pure expression.
A somewhat bizarre workaround is to make a fake call to a method just to satisfy this warning. I've chosen `scala.Predef.identity` here so it can be composed together with the existing expression nesting when they exist.
Issue #5974 reported that ctrl+d was not working as expected in the
scala 2.13.{2,3} console. This was because we were throwing an exception
whenever ctrl+d was read instead of allowing the jline line reader to
handle it. I can't remember exactly why I added the throw here but I
validated that both the sbt shell and the scala console had the expected
behavior from the comments in #5974 after this change.
When project/target is a symbolic link, sbt 1.4.0 crashes on startup
because Files.createDirectories will throw a FileAlreadyExistsException.
The fix is to first check if the target directory exists before trying
to create it.
eugene yokota
Ethan Atkins
xuwei-k
Guillaume Martres
Taichi Yamakawa
Taichi Yamakawa
Nader Ghanbari
Adrien Piquerez