Add logging of various operations the transactional class file manager is
doing. You can pass logger to be used by the transactional class file
manager by using overloaded definition of `ClassfileManager.transactional`
method. The old overload has been deprecated.
The factory methods for class file manager in IncOptions companion object
has been deprecated in favor of using ClassfileManager companion object
directly. The code in Defaults.scala has been updated to use non-deprecated
methods. The logging is turned off by default.
The canonical way of enabling transactional class file manager in sbt
project is:
```
incOptions := incOptions.value.withNewClassfileManager(
sbt.inc.ClassfileManager.transactional(
crossTarget.value / "classes.bak",
(streams in (compile, Compile)).value.log
)
)
```
It's a bit verbose which shows that the api for this is not the best.
However, I don't expect sbt users to need this code very often.
This patch should help debug the problem described in #1184
The deprecated method should forward to the other overloaded alternative
but it recursed instead.
This kind of mistake would be easily caught by linter warning about
unused `newConfig` local variable. I hope we'll get there some day.
Fixes#1251
`DefaultOptions.addResolvers` and `DefaultOptions.addPluginResolvers`
should not reset the existing value while adding the new ones. The
names are prefixed with _add_ afterall.
`DefaultOptions.addResolvers` and `DefaultOptions.addPluginResolvers`
should not reset the existing value while adding the new ones. The
names are prefixed with _add_ afterall.
1) When `test` is run and there are no tests available, omit logging output.
Especially useful for aggregate modules. `test-only` et al unaffected. (#1185)
2) Added a new setting `testResultLogger` to allow customisation of logging of test results.
* Expose new EvaluateTaskConfig throughout all the APIs
* Create a key for cancellation configuration
* Add default values for cancellation in GlobalPlugin
* Create a test to ensure that cancellation can cancel tasks.
* Deprecate all the existing mechanisms of evaluating tasks which
use the EvaluateConfig API.
* Create a new EvaluateTaskConfig which gives us a bit more freedom
over changign config options to EvaluateTask in the future.
* Create adapted from old EvaluateTask to new EvaluateTask
* Add hooks into signals class to register/remote a signal listener
directly, rather than in an "arm" block.
* Create TaskEvaluationCancelHandler to control the strategy of
who/whom can cancel (sbt-server vs. sbt-terminal).
* Create a null-object for the "can't cancel" scenario so the
code path is exactly the same.
This commit does not wire settings into the build yet, nor does it
fix the config extractio methods.
It has been reported in sbt/sbt#1237 that stack overflows may occur during the
extraction of used names (and later of dependencies between files). This
problem has been introduced by sbt/sbt#1163, which was about recording the
dependencies of macro arguments.
When a macro is expanded, the compiler attaches the tree before expansion to
the tree representing the expanded macro. As of Scala 2.11-RC3, some macros
have themselves attached as original tree, which caused the same macro to be
inspected over and over until a stack overflow.
This commit solves this problem by making sure that the original of a macro
expansion will be inspected if and only if it is different from the expanded
tree.
Fixessbt/sbt#1237
Add two scripted tests that illustrate a problem occurring with Scala 2.11-RC3
where some macros have themselves attached as original tree, which causes a
stack overflow during dependency extraction.
* sbt 0.12.3 introduced sbt/sbt@482f99 to fix#637 and #641.
* The underlying issue of #641 was an incorrect classifier, and it was
fixed in sbt/sbt@718fa9 for #683 and shipped as sbt 0.13.0.
Prior to this commit, a class that inherited a macro from another
class was considered by incremental compiler as having a macro.
Now, only classes that explicitly define a macro are considered as having
a macro. This influences decision whether to invalidate (recompile)
dependencies of a file that inherits a macro upon a whitespace change.
From now on, we don't invalidate dependencies in such case which
results in much better incremental compiler experience when macros are
being involved. Check #1142 for detailed discussion.
The change to the behavior is reflected by marking the
source-dependencies/inherited-macros test as passing.
The source-dependencies/macro test covers the case of defining the macro
directly in source file. Therefore we know that the desired behavior of
invalidating dependencies of macros is preserved.
Fixes#1142
Add a scripted test documents the current behavior of incremental
compiler when it comes to handling of inherited macros. A whitespace
change to a file that inherits a macro triggers recompilation of all files that
depend (by composition or inheritance) on that file.
Grzegorz Kossakowski
Josh Suereth
Indrajit Raychaudhuri
eugene yokota
David Barri
Martin Duhem
Jacek Laskowski
Dan Sanduleac
Ismael Juma