…ass it a nested class.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84557991

… essentially as a todo), and depend on the released auto-value.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84571281

…ods &

parameters.  With support for implicit generic types, this otherwise printed
out the unresolved methods/parameters, and was confusing.

In fixing this, I also cleaned up the general listing of the dependency chain
so that variables aren't suffixed with '()', and so that raw types are skipped
(since they're synthetic dependencies due to the way members injectors are
implemented, not real things that folks care about).
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84577408

…process, clean up general support for subclassing modules & add a lot of validation. The rules are:

a) Modules may be subclasses and may be subclassed.
b) @module(includes) from parent classes are unioned into the child's dependencies.
c) @provides methods may not be overridden or override another method.
d) Modules referenced by @module(includes) must not be abstract.
e) Modules referenced by @module(includes) must have the same @module annotation.
f) @component(modules) must not be abstract.
g) If a Module has type parameters, it must be abstract.

(None of this validation existed before, though some of it should have.)
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84582926

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84670820

…sponding functional test.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84696369

…ment, but can be called statically. Then, clean up all of the places that callers to MoreTypes.asTypeElement were passing through a Types instance just for that reason.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84753119

… interoperability with Guice.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84836495

…t now ensures that Dagger does not generate any code that uses Guava.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84889646

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84889738

…types or

unbounded types.

In a better world, I would analyze the required dependencies of the members
injected type (and its superclass' dependencies) and allow raw or unbounded
parameters if none of the parameters were used as actual dependencies.
Unfortunately, that's really hard to get right.  So might as well fail with a
sane error message for now until someone gets around to doing it better.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85010484

…e not themselves @component interfaces.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85067567

…it's a "use at your own risk" feature, but that is forthcoming.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85091489

… marked @nullable cannot by injected by an @provides or component method that has @nullable.

Also generate null-checks in provision factories & component factories if they aren't @nullable.

This can be controlled by a "dagger.nullableValidation={ERROR,WARNING}" flag, with the default being ERROR.  WARNING will cause compilation to produce warnings when there's a nullable mismatch, and will ignore null return values from providers/component methods. ERROR will trigger the new behavior.

This also changes compile-testing to support passing options to the compiler.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85151739

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85157486

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85180709

Explicitly mark [] to use WARNING, since they're full of errors.
Global TAP looks pretty happy: []
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85283950

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85435991

…face for Producer<T> has a ListenableFuture<T> get() method but the codegen was creating a T get() method.

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=85519772

…d to figure out if we want to revert that and force the functional tests back to 1.6, or just leave it, since the functionality isn't any different.