Add EnumSection to allow decorators to modify enum member attributes

[Dorenavant]

Motivation and Context

Allows users to use decorators to add additional attributes to members of an enum.

N/A

Description

Adds EnumSection with named AdditionalMemberAttributes to allow decorators to modify enum codegen.

Testing

Could not find existing unit tests for customizations; please advise if you would like them to be added here. Ran ./gradlew to ensure current tests pass.

Checklist

• For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "client," "server," or both in the applies_to key.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[aajtodd]

Can you describe what problem this solves and an example of a using it?

[Dorenavant]

Can you describe what problem this solves and an example of a using it?

In our case, we're trying to add a #[serde(rename = "name")] to the Enum members. We add #[derive(Deserialize)] to the Enum to help deserialize the output shapes of our smithy API, but this is causing problems when an enum has a value override, e.g.

enum Foo {
  Bar = "NotBar"
}

Then the string "NotBar" isn't able to be deserialized into Foo::Bar.

A user could then implement a ServerCodegenDecorator that calls extraSections

smithy-rs/codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/customize/CoreCodegenDecorator.kt

Line 118 in c63e792

fun extraSections(codegenContext: CodegenContext): List<AdHocCustomization> = listOf()

to add custom member attributes here.

[Dorenavant]

Hey team, could we get some eyes on this please? Or if there is another way to customize attributes on enum members, can you please let us know?

[drganjoo]

We appreciate the feature addition! I'm wondering if we could refactor this slightly to make it more consistent with our existing architecture.

It seems a bit cleaner to move this customization out of EnumMemberModel and into our abstract class pattern. Since we already have methods for adding attributes to the Enum itself, what if we extend this approach with:

abstract class EnumType {
    /** Returns a writable that implements `From<&str>` and/or `TryFrom<&str>` for the enum */
    abstract fun implFromForStr(context: EnumGeneratorContext): Writable

    /** Returns a writable that implements `FromStr` for the enum */
    abstract fun implFromStr(context: EnumGeneratorContext): Writable

   // other functions...

   /** Optionally add more attributes to each variant of the enum */
    open fun additionalEnumVariantAttributes(context: EnumMemberModel): List<Attribute> = emptyList()

We will call this function in RustWriter.renderEnum:

        context.enumMeta.render(this)
        rustBlock("enum ${context.enumName}") {
            context.sortedMembers.forEach { member ->
                enumType.additionalEnumVariantAttributes(member).forEach { attribute ->
                    attribute.render(this)
                }
                member.render(this)
            }
            enumType.additionalEnumMembers(context)(this)
        }

This would allow concrete classes to override and add custom attributes to enum variants in a way that's consistent with our current pattern.

The only trade-off would be a slight change in the output order: attributes would appear first, followed by docs and deprecated markers, and then the variant name:

enum Suit {
    #[serde(rename="diamond")]
    /// Docs go here
    /// Deprecated goes here
    Diamond
}

Would this approach work for your use case? I think it gives us the same functionality while maintaining architectural consistency.

[Dorenavant]

This would work for us, I'll do the refactor thank you

Please see below comment

[Dorenavant]

Sorry, I lost context here. After ramping myself back up to speed, I'm not sure this solves our use case. We're trying to avoid overriding the enum generation completely, but instead use a decorator to modify the existing EnumGenerator behaviour. By adding a decorator that uses the extraSections (

smithy-rs/codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/customize/CoreCodegenDecorator.kt

Line 118 in c63e792

fun extraSections(codegenContext: CodegenContext): List<AdHocCustomization> = listOf()

), we can get this behaviour without having to override the EnumGenerator class. There is an existing pattern for this in the codebase

smithy-rs/codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/generators/StructureGenerator.kt

Lines 41 to 54 in c63e792

	sealed class StructureSection(name: String) : Section(name) {
	abstract val shape: StructureShape
	/** Hook to add additional fields to the structure */
	data class AdditionalFields(override val shape: StructureShape) : StructureSection("AdditionalFields")
	/** Hook to add additional fields to the `Debug` impl */
	data class AdditionalDebugFields(override val shape: StructureShape, val formatterName: String) :
	StructureSection("AdditionalDebugFields")
	/** Hook to add additional trait impls to the structure */
	data class AdditionalTraitImpls(override val shape: StructureShape, val structName: String) :
	StructureSection("AdditionalTraitImpls")
	}

for the StructureGenerator to inject additional behaviour into the base StructureGenerator.

[drganjoo]

There is an existing pattern for this in the codebase

I have a broader architectural consideration: ideally, the Context should focus on elements directly from the Smithy model (shapes and related constructs) rather than including details specific to Rust code generation. For such implementation-specific concerns, leveraging the symbol provider would be architecturally cleaner.

That said, you've made a valid observation. We've already implemented this pattern for StructureGenerator. Given that precedent, extending the same approach to EnumGenerator would follow the established design pattern.

We can consider a more comprehensive refactoring of the Context/symbol provider responsibilities as a separate improvement effort if needed at a later stage.

[Dorenavant]

Thanks for the approval! I realized it would be handy to have AdditionalTraitImpls as a hook in these sections as well, going to make another commit.

[landonxjames]

Looks like there are quite a few CI failures, all similar to:

> Task :codegen-core:jar
e: file:///home/build/workspace/smithy-rs/codegen-server/src/main/kotlin/software/amazon/smithy/rust/codegen/server/smithy/generators/ServerEnumGenerator.kt:169:9 No value passed for parameter 'customizations'

> Task :codegen-server:compileKotlin FAILED
e: file:///home/build/workspace/smithy-rs/codegen-client/src/main/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGenerator.kt:286:9 No value passed for parameter 'customizations'

> Task :codegen-client:compileKotlin FAILED

[Dorenavant]

Looks like there are quite a few CI failures, all similar to:

> Task :codegen-core:jar
e: file:///home/build/workspace/smithy-rs/codegen-server/src/main/kotlin/software/amazon/smithy/rust/codegen/server/smithy/generators/ServerEnumGenerator.kt:169:9 No value passed for parameter 'customizations'

> Task :codegen-server:compileKotlin FAILED
e: file:///home/build/workspace/smithy-rs/codegen-client/src/main/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGenerator.kt:286:9 No value passed for parameter 'customizations'

> Task :codegen-client:compileKotlin FAILED

I see what's wrong, pushing a fix

[landonxjames]

Getting closer, looks like its the tests failing now:

> Task :codegen-client:classes
e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGeneratorTest.kt:31:46 No value passed for parameter 'customizations'

e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGeneratorTest.kt:91:42 No value passed for parameter 'customizations'
e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGeneratorTest.kt:126:42 No value passed for parameter 'customizations'
> Task :codegen-client:compileTestKotlin FAILED
15 actionable tasks: 15 executed
e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientEnumGeneratorTest.kt:159:42 No value passed for parameter 'customizations'
e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientInstantiatorTest.kt:56:49 No value passed for parameter 'customizations'
e: file:///home/build/workspace/smithy-rs/codegen-client/src/test/kotlin/software/amazon/smithy/rust/codegen/client/smithy/generators/ClientInstantiatorTest.kt:77:49 No value passed for parameter 'customizations'

FAILURE: Build failed with an exception.

[landonxjames]

Couple of small formatting things, but otherwise looks good. In favor of shipping if we can get all the CI failures cleaned up.