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.
* 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.
Josh Suereth
David Barri
eugene yokota
Grzegorz Kossakowski
Martin Duhem
Matej Urbas
Jacek Laskowski