@Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
      if (!generated) {
        generated = true;
        // Check that AutoValueProcessor has already run and deferred the foo.bar.Test type because
        // we haven't generated its parent yet.
        expect.that(autoValueProcessor.deferredTypeNames()).contains("foo.bar.Test");
        GENERATED_TYPES.forEach(
            (typeName, source) -> {
              try {
                JavaFileObject generated = processingEnv.getFiler().createSourceFile(typeName);
                try (Writer writer = generated.openWriter()) {
                  writer.write(source);
                }
              } catch (IOException e) {
                throw new UncheckedIOException(e);
              }
            });
      }
      return false;
    }
Tests behaviour when the package containing an {@code @AutoValue} class also has classes with
the same name as classes in {@code java.lang}. If you call a class {@code Object} you are
asking for trouble, but you could innocently call a class {@code Compiler} without realizing
there is a {@code java.lang.Compiler}.

<p>The case where the class in question is mentioned in the {@code @AutoValue} class is the
easy one, because then our logic can easily see that there is a clash and will use
fully-qualified names. This is the case of the {@code Compiler} class below. The case where the
class is <i>not</i> mentioned is harder. We have to realize that we can't elide the package
name in {@code java.lang.Object} because there is also a {@code foo.bar.Object} in scope, and
in fact it takes precedence.
value/src/test/java/com/google/auto/value/processor/AutoValueCompilationTest.java