allow defining generic type constraints for swift

[darrell-roberts]

This updates how generic type constraints are applied to swift types. Before if a type had a generic member we would implicitly apply the same type constraints to the generic constraints. That is not always desirable. This allows the user to define the generic type constraints via the swiftGenericConstraints typeshare attribute.

See example in core/data/tests/generic_struct_with_constraints_and_decorators/input.rs.

Also removed excessive allocations in swift.rs.

Introduced swift config option codablevoid_constraints which allows defining constraints for CodableVoid.

[charlespierce]

It feels a bit awkward here (and elsewhere, especially in the kotlin section) to have to first get the values for a specific language, and then drill down into the decorators that match the kind we are looking for. Now that we have multiple decorators for a single language (and we already don't support decorators for every language), would it be unreasonable to decouple the decorator type from the SupportedLanguage struct?

If we had a DecoratorKind enum that included the supported decorators (e.g. Kotlin, Swift, and SwiftGenericConstraints), and then built the map of DecoratorKind => Vec of values, the API would be roughly similar to what it is now, but allowing multiple kinds of decorators to be pulled when they are relevant.

[darrell-roberts]

Yup, I agree. Pushed the update.

[charlespierce]

Overall LGTM! Left one suggestion for cleaning up the need to pass Cow into a helper, but that's not blocking. I'm still waiting on some more info about the release process, so I'll look to merge this in the morning. If you get to making that change by then, great; if not, happy to have it as a follow-up PR since it doesn't really affect the working of the module, just the dev ergonomics.

[charlespierce]

Love using a BTreeSet here instead of sorting & deduping as part of importing 🎉

[charlespierce]

Returning Cow<str> here makes a lot of sense, however needing to pass one in strikes me as a bit of an anti-pattern. It looks like that might be used to avoid lifetime issues with the format! calls above and "value dropped while borrowed" or something? If so, would it be reasonable to take an Into<Cow> to avoid needing to update all of the call sites? I'm thinking something like:

fn swift_keyword_aware_rename<'a, T>(name: T) -> Cow<'a, str>
where
    T: Into<Cow<'a, str>>,
{
    let name = name.into();
    if SWIFT_KEYWORDS.contains(&name.as_ref()) {
        Cow::Owned(format!("`{name}`")
    } else {
        name
    }
}

That way we still avoid the extra allocations, but we can directly pass either a String or &str into the method without needing to explicitly annotate Cow::Owned or Cow::Borrowed at the call site.

[darrell-roberts]

Yup I felt I missed something when repeatedly wrapping in Cow. Pushed update.

[charlespierce]

This is a nice pattern! I don't think I've seen Either used like this for the two branches to allow a simple iterator fold at the end, but it's a lot more readable than collecting into an intermediate vector.