sbt/sbt — pull request #998 by dansanduleac (2013-11-22 19:02:26+00:00)
Title: Fix deriveAndLocal bug

In my quests to derive some settings, I have noticed that one of my 2 `DerivedSetting`s was actually derived, but the other one which depended on the first one, did not. Let's call them A and B, B depending on A (both representing their respective values of type `Derived`. To note is that B depended not just on A, but on a plain setting C as well, which is relevant.
Turns out, the issue was that in `def localAndDerived`, `(d: Derived).inScopes` has the new scope added to it, even if the derived setting `d` didn't actually resolve yet, because not all of its dependencies were defined yet. In this case, it happened when processing the B's "plain setting" dependency C.
This had the effect that at the time when all of B's dependencies came to be defined (i.e. A got derived), it became possible that the same scope had already been added to B (because both B's dependencies, A and C, were defined in the same scope), so no further attempts to check B's dependencies by calling `allDepsDefined` were made anymore, leaving B forever undefined.

As an aside note, that also prompted me to look at `val sortedDerivs` in deriveAndLocal, and noticing that it's not used - presumably the topological sort is only called to issue warnings about cycles?

Sorry about spacing diffs, that was as a result of retabbing.

I believe this patch is applicable to 0.13 as well, as the last commit that touched this is `4bb9633` slightly after 0.13.0-M2.