Fix issue where struct associated values in enums couldn't be encoded/decoded automatically

[ben-p-commits]

Summary

Fixes encoding and decoding of enums with struct associated values. Previously, these would fail with SchemaMissing errors or silently lose data (That silent data loss is what I've been experiencing in my own project).

Root Cause

When Swift encodes enums with associated values, it uses nestedContainer(keyedBy:forKey:) to create a container nested inside the enum case name. The bug was that nested containers were using their parent's impl.codingPath instead of their own codingPath when encoding child values.

This caused the struct data to be written one level too high in the document hierarchy:

Before (broken):

value
  ├─ _0 (Map) - struct data at wrong level
  └─ simple (Map) - empty

After (fixed):

value
  └─ simple (Map)
      └─ _0 (Map) - struct data at correct level

This PR assumes that when working in a nested container, we should always trust the container's own codingPath, not the shared impl.codingPath, because the container knows where it actually is in the tree.

Changes

Updated path calculation in 6 locations across 2 files to use the container's own codingPath instead of impl.codingPath. These changes were made in:

• AutomergeKeyedEncodingContainer.swift
• AutomergeUnkeyedEncodingContainer.swift.

Testing

Added comprehensive test suite (EnumAssociatedValueTests.swift) with coverage for a variety of enum + associated value scenarios.

All tests now pass.

Impact

I don't believe this is a breaking change.

• This fix only affects code paths that were previously broken (throwing errors or losing data).
• All previously working code should continues to work unchanged.
• Regarding scalar value backward compatibility: If a document was serialized prior to a version with this change, it will be fine. This only affected multi-level nesting. Primitives in enums can still be decoded after these changes even if they were encoded before.

Enables new functionality:

• Enums with struct associated values can now be encoded/decoded
• Any deeply nested structures using nested containers now work correctly

fixes #223

[ben-p-commits]

@alexjg - before kicking off the workflow again for this one- CI is blocked by two failures- one of which is an issue with rust toolchain versioning.

Here's a separate PR with a fix for that:
#225

[alexjg]

Apologies for the slow response here. I'll try and find time to review this tomorrow.

[ben-p-commits]

Merged in main with fix for updated rust toolchain #225 .

[ben-p-commits]

I was able to get the tests to pass with the swift-6.2.3-RELEASE_wasm SDK. A good sign. will try with swift-DEVELOPMENT-SNAPSHOT-2024-10-08-a as well locally.

[ben-p-commits]

I can't do much more to mimic the CI environment without installing old Xcodes at this point (and I'm lazy). My current version ships with Swift 6.2, so the macOS SDK itself is compiled against 6.2... The 6.1.3 toolchain can't even parse Package.swift because it can't import Foundation.

IMO I think we should consider just bumping the CI environment to use a newer version of the swift wasm sdk- perhaps swift-6.2.3-RELEASE_wasm to just rip off the bandaid. Our build + tests seem happy using the latest version in my testing.

will wait for your feedback @alexjg before I open another PR to tackle the proposed CI changes.

[alexjg]

I'm comfortable bumping the CI version, if you have time to put together a PR doing so I'll approve it

[ben-p-commits]

@alexjg - PR opened, tests passing 😮‍💨
#226

[alexjg]

I've merged that PR (and thank you!) if you rebase this one we can hopefully get it merged

[ben-p-commits]

Nice, happy to help @alexjg. Thanks for your eyes on this stuff.

edit* success! 😮‍💨

[ben-p-commits]

@alexjg - should be ready to roll for your review + merge if and when you have time this week. Thanks again!