* AutoImport trait is subsumed by def autoImport method under
AutoPlugin class.
* When def autoImport is overridden by a lazy val or a val, *.sbt
automatically imports autoImport._.
Add test analogous to source-dependencies/macro-arg-dep
but check if dependencies of nested macro applications are handled
properly. Nested macro applications are tricky because we have to look
into original (before macro expansion) trees recursively. This test verifies
that.
Add a unit test which checks whether we capture dependencies introduced
by arguments to macros. Those dependencies are special because macros
get expanded during type checking and arguments to macros are not visible
during regular tree walk.
It was not possible to make `ScalaCompilerForUnitTesting` compile several
files in different runs, which means that it was not possible to compile
and use a macro in a test case, since macros cannot be used in the same
compilation run that defines them.
This commit allows a test case to provide multiple grouped snippets of
code that will be compiled in separate runs.
For instance :
List(Map(<snippet A>, <snippet B>), Map(<snippet C>))
Here, <snippet A> and <snippet B> will be compiled together, and then
<snippet C> will be compiled, and will be able to use symbols defined
in <snippet A> or <snippet B>.
Macros take arguments as trees and return some other trees; both of
them have dependencies but we see trees only after expansion and
recorded only those dependencies.
This commit solves this problem by looking into the attachments of the
trees that are supposed to contain originals of macro expansions and
recording dependencies of the macro before its expansion.
This allows plugins to define a Plugins instance that captures both the
plugin and its required dependencies.
Also fixed up some scaladocs that were wrong.
* packageArtifacts is not cleared by defautlSettings
* Added a test for this behavior (this one test should ensure the ordering for most settings is correct.)
Fixes#1176
For some reason, autoSettings fixes for tests disappeared.
* Fixes setting orderings now that defaults come from autoPlugins
* Removes autoPlugin settings where expected.
* Fill out more details in archiecture section.
* Leave sections blank we don't have time to write.
* Consolidate on `Sub project` vernacular instead of module.
* Add a few examples to make statements concrete.
We cannot break existing users, but we can deprecate the improper usage.
This is part #2 of the workaround for #1156. This ensures that
users will stop using the legacy methods after 0.13.2 is out.
AddSettings should only expose coarse-grained features of AutoPlugins
or else the Logic we use to ensure safe addition completely breaks
down. Leaving it in the code as an escape hatch if we get desparate,
but we need an alternative for controlling ordering later.
* Add notes about AutoPlugins vs. RootPlugins in Plugins section
* Modify best practices section to recomend using AutoPlugins.
* Modify Using-Plugins section in getting started to denote
auto plugins.
Eugene Yokota
Josh Suereth
Sergey Andreev
Martin Duhem
Grzegorz Kossakowski
Dan Sanduleac
James Roper
Havoc Pennington