Specifically, when the Scala version for sbt is the same as that for the project being built,
the jars in UpdateReport should be the same as those in ScalaProvider. This is because the
loader will come from the ScalaProvider, which uses jars in the boot directory instead of the
cache. The first part of the fix for #661 checks that loaded classes come from the classpath
and so they need to line up.
Introduce a way to configure incremental compiler itself instead
of underlying Java/Scala compiler.
Specific list of changes in this commit:
* Add a method to `xsbti.compile.Setup` that returns incremental
compiler options as a `java.util.Map<String, String>`. We considered
statis interface instead of a `Map` but based on mailing
list feedback we decided that it's not the best way to go because
static interface is hard to evolve it by adding new options.
* Since passing `java.util.Map<String, String>` not very convenient
we convert it immediately to `sbt.inc.IncOptions`
* Add options argument to various methods/classes that implement
incremental compilation so in the end options reach
`sbt.inc.IncOptions` object
* Add `incOptions` task that allows users to configure incremental
compiler options in their build files. Default implementation of
that tasks returns just `IncOptions.DEFAULT`
* Both system property `xsbt.inc.debug` and `IncOptions.relationsDebug`
trigger debugging of relations now. In the near future, we should
deprecate use of `xsbt.inc.debug`.
Needed an explicit type in PMap to workaround an error.
Need to drop tuple assignment of parser.parsed in input task macro as a workaround
for macro/resetAllAttrs/pattern matching/annotation issue in RC1.
1. Hyphenated labels are still accepted when parsing scoped keys (so 'sbt test-only' still works)
There is currently no timeline for removing this support for hyphenated keys.
2. Only camelCase is shown for tab completion.
3. AttributeKey.rawLabel provides the unnormalized label.
This should only be used to implement support for accepting hyphenated keys as input for compatibility.
4. AttributeKey.normLabel provides the normalized label (hyphenated converted to camelCase)
Similar to task macros, the parsed value is accessed by calling `parsed`
on a Parser[T], Initialize[Parser[T]], or Initialize[State => Parser[T]].
Values of tasks and settings may be accessed as usual via `value`.
That is, implement Initialize[Task[T]].flatten correctly.
This requires preserving the transformations applied in a scope so that
they can be applied to an Initialize value after static settings have been
evaluated.
* use normal TypeTree constructor
* remove unnecessary 'with Singleton' in macro utility
* integrate changes suggested by @xeno-by
* add refVar back and call asTypeConstructor instead of asType to refer to a type variable
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
Mark Harrah
cheeseng
Alex Dupre
Grzegorz Kossakowski
Paolo G. Giarrusso
Anthony