OrphanedShapes TestModel

[lucasmcdonald3]

Smithy-Dafny .NET and Java support "orphaned shapes".

"Orphaned shapes" are shapes that exist in a Smithy model, but aren't discovered by Smithy-Core's shape discovery mechanism.

Smithy-Core will only discover and generate code for shapes that are attached to a service via the service's

1. Operations
2. Mixins
3. Errors

and recursive traversals of the connected shapes.

If a shape is defined in a Smithy model, but not used in a LocalService's operations or errors, codegens that use Smithy-Core's shape discovery will not generate code for the shape.

The expectation from Smithy-Dafny .NET/Java is that code is generated for these shapes.

[robin-aws]

The more fundamental inconsistency is the fact that smithy-dafny generates code for all shapes in a namespace, instead of in the service closure as the other Smithy code generators do. Including orphaned shapes is the main consequence. There may be others.

The Rust codegen currently special-cases an orphaned "input structure" in the DDB model because of this. (Edit: actually it's on the branch I haven't merged yet: https://github.com/smithy-lang/smithy-dafny/blob/robin-aws/support-dependencies-on-rust/codegen/smithy-dafny-codegen/src/main/java/software/amazon/polymorph/smithyrust/generator/RustAwsSdkShimGenerator.java#L324-L326)

See also #605.

[robin-aws]

I skipped over the actual issue title in my response. I do think we should eventually make smithy-dafny more consistent with the other smithy-<lang> code generators and generate for shapes in the service closure instead of a given namespace.

At the same time the @localService$config member creates a new edge in the graph that should be considered part of the service closure. I don't yet know how easy it is to coerce an existing Smithy code generator to be aware of that edge.

So if the test case you want is about local service config shapes, that implies augmenting the Constructor test model, or perhaps creating another similar one. If you want to assert how smithy-dafny handles other cases of orphaned shapes, then sure we could have an OrphanedShapes test model for various cases where smithy-dafny also still shouldn't generate code (and there is already a case of this in the DDB model as above).