@Test
  public void generatedParentWithGeneratedGetterButSetterInBuilder() {
    JavaFileObject test =
        JavaFileObjects.forSourceLines(
            "foo.bar.Test",
            "package foo.bar;",
            "",
            "import com.google.auto.value.AutoValue;",
            "import foo.baz.GeneratedParent;",
            "import foo.baz.GeneratedPropertyType;",
            "import java.util.Optional;",
            "",
            "@AutoValue",
            "public abstract class Test extends GeneratedParent {",
            "  public abstract String string();",
            "",
            "  public static Builder builder() {",
            "    return new AutoValue_Test.Builder();",
            "  }",
            "",
            "  @AutoValue.Builder",
            "  public abstract static class Builder extends GeneratedParent.Builder<Builder> {",
            "    public abstract Builder setString(String x);",
            "    public abstract Builder setGenerated(GeneratedPropertyType x);",
            "    public abstract Test build();",
            "  }",
            "}");
    AutoValueProcessor autoValueProcessor = new AutoValueProcessor();
    GeneratedParentProcessor generatedParentProcessor =
        new GeneratedParentProcessor(autoValueProcessor, expect);
    Compilation compilation =
        javac()
            .withProcessors(autoValueProcessor, generatedParentProcessor)
            .withOptions("-Xlint:-processing", "-implicit:none")
            .compile(test);
    assertThat(compilation).succeededWithoutWarnings();
    assertThat(compilation)
        .generatedSourceFile("foo.bar.AutoValue_Test")
        .contentsAsUtf8String()
        .contains("  public int integer() {");
  }
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