StackOverflow caused by recursive uses declaration

[andrewsleeman24]

Today I did battle with mapstruct because I accidentally implemented a class with a self referencing "uses" declarations.

...
@Mapper(config = MapStructConfig.class //
		, uses = TodoMapper.class //
)
public interface TodoMapper {
    public TodoResponse toResponse(TodoJpa jpa);
...

I do realise this is my mistake and not a functional issue with mapstruct.
However if possible it would have been nice to have an error explaining my fault, rather than a stacktrace like the following:

[ERROR] .../TodoMapper.java:[12,8] Internal error in the mapping processor: java.lang.StackOverflowError at com.sun.tools.javac.code.Type.hasTag(Type.java:112) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1967) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1968) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1975) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1975) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types$4.visitClassType(Types.java:921) at com.sun.tools.javac.code.Types$4.visitClassType(Types.java:844) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.isSubtype(Types.java:840) at com.sun.tools.javac.code.Types.isSubtype(Types.java:804) at com.sun.tools.javac.model.JavacTypes.isSubtype(JavacTypes.java:98) at org.mapstruct.ap.internal.util.workarounds.SpecificCompilerWorkarounds.isSubtype(SpecificCompilerWorkarounds.java:63) at org.mapstruct.ap.internal.util.workarounds.TypesDecorator.isSubtype(TypesDecorator.java:55) at org.mapstruct.ap.internal.model.common.TypeFactory.getType(TypeFactory.java:192) at org.mapstruct.ap.internal.model.common.TypeFactory.getType(TypeFactory.java:182) at org.mapstruct.ap.internal.model.common.TypeFactory.getParameters(TypeFactory.java:392) at org.mapstruct.ap.internal.model.common.TypeFactory.getParameters(TypeFactory.java:377) at org.mapstruct.ap.internal.model.common.TypeFactory.getSingleParameter(TypeFactory.java:368) at org.mapstruct.ap.internal.model.common.Type.determineTargetType(Type.java:620) at org.mapstruct.ap.internal.model.common.Type.getPropertyWriteAccessors(Type.java:570) at org.mapstruct.ap.internal.model.source.TargetReference$BuilderFromTargetMapping.getTargetEntries(TargetReference.java:190) at org.mapstruct.ap.internal.model.source.TargetReference$BuilderFromTargetMapping.build(TargetReference.java:158) at org.mapstruct.ap.internal.model.source.Mapping.init(Mapping.java:446) at org.mapstruct.ap.internal.model.source.Mapping.init(Mapping.java:413) at org.mapstruct.ap.internal.model.source.SourceMethod$Builder.build(SourceMethod.java:200) at org.mapstruct.ap.internal.processor.MM ethodRetrievalProcessor.getMethodRequiringImplementation(MethodRetrievalProcessor.java:261) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.getMethod(MethodRetrievalProcessor.java:188) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:143) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:158) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:158) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:158) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:158) at org.mapstruct.ap.internal.processor.MethodRetrievalProcessor.retrieveMethods(MethodRetrievalProcessor.java:158) at ...
Thanks, Andrew

[filiphr]

You are completely right @andrewsleeman24 we should provide a better error message or we can completely remove the duplicate entry as well.

In any case there shouldn't be any Stackoverflow exception. We'll look into this for the next release

[sjaakd]

I guess this is a duplicate of #476 .. The case is a bit more elaborate, because also A uses B uses A should be covered instead of A uses A

[filiphr]

I think that it is slightly different. Cycled mappers do actually work, Mapper#getMapper doesn't work in that case, but cyclic dependency does work for this.

However, we can't have the same mapper in uses.