ADT unions are prone to member naming conflicts

[kubukoz]

Given:

$version: "2"
namespace a

@smithy4s.meta#adt union U { a: a#A, b: b#A }

structure A{}

and

$version: "2"

namespace b

structure A {}

Generating code will cause compilation conflicts in U:

[error] ./a/U.scala:47:3
[error] A is already defined as class A
[error] ./a/U.scala:51:3
[error] A is already defined as object A
[error] ./a/U.scala:26:16
[error] object A in object U does not take parameters
[error]   def a(): A = A()
[error]                ^
[error] ./a/U.scala:27:16
[error] object A in object U does not take parameters
[error]   def a(): A = A()
[error]                ^
[error] ./a/U.scala:43:38
[error] object A in object U does not take parameters
[error]     val schema: Schema[A] = constant(A()).withId(id).addHints(hints)
[error]                                      ^
[error] ./a/U.scala:27:7
[error] Conflicting definitions:
[error] def a(): a.U.A in object U at line 26 and
[error] def a(): a.U.A in object U at line 27
[error] have the same type (): a.U.A after erasure.
[error]
[error] Consider adding a @targetName annotation to one of the conflicting definitions
[error] for disambiguation.
[error]   def a(): A = A()
[error]       ^

Relevant code:

  def a(): A = A()
  def a(): A = A()

  final case class A() extends U {
    def $ordinal: Int = 0
  }

  object A {
...
  }
  final case class A() extends U {
    def $ordinal: Int = 1
  }

  object A {
 ...
  }

[kubukoz]

This will also happen if the members are @adtMembers. Plain unions will be fine, because their members and factory methods are named according to the Smithy member name (which are unique).

As for a solution, we could detect naming conflicts and, if one is found, qualify the members with the member name. In this case, e.g.

def a_a()
def a_b()

case class A_A()
case class A_B()

or, better yet, we make the factory methods always named after the members - then only the case classes need to be renamed. As an added benefit, we'd gain more consistency between the factory methods and the project methods (which are named after the member already, unconditionally).