feat: add option through .udl to rename objects and functions i

[gruberb]

• DISCO-2879

• Closes https://github.com/mozilla/uniffi-rs/issues/1426

---

We want to allow renaming of functions and variables. This PR adds the ability to add the following to a uniffi.toml file:

[bindings.kotlin.rename]
OtherError = "AnotherError"

[bindings.python.rename]
OtherError = "AnotherError"

[bindings.ruby.rename]
UnknownError = "UnspecificError"

[bindings.swift.rename]
OtherError = "AnotherError"

Which will rename whatever enum, function or struct, constant or other parameter matches the name, to the name in the double quotes to the right.

For this, we extend the filter functions in the templates for each language, and pass down the config variable. From there, we read the additional rename parameter, and check for a match.

Example: Python class_name:

pub fn class_name(nm: &str, config: &Config) -> Result<String, askama::Error> {
    if let Some(overwrite_class_name) = config.rename.get(nm) {
        return Ok(PythonCodeOracle.class_name(overwrite_class_name));
    }
    Ok(PythonCodeOracle.class_name(nm))
}

And this will be picked up in the template:

{%- let variant_type_name = variant.name()|class_name(config) -%}

ToDo

• [x] Python
• [x] Swift
• [x] Kotlin
• [x] Ruby

Testing

• [x] Python
• [x] Swift
• [x] Kotlin
• [x] Ruby

Open

I have to figure out if that's currently possible for Ruby. Would need a second pair of eyes, as this is my first PR in this repository.

[gruberb]

Updated the PR, needs some review again. I am not quite sure how we directly map Rust types to the foreign type bindings. Like: https://github.com/mozilla/uniffi-rs/pull/2176/files#diff-522f0ef157bc0a32453bafd790a9058a35cbb8a721df58a9b51b1ec6b74db5caR543-R554

I think both an enum and a struct can end up as type_name for example in Kotlin. So I check both. I think this will be tackled with this issue (https://github.com/mozilla/uniffi-rs/issues/2184) in the future.

[gruberb]

I'm currently thinking that the best place to do the renames is in the code oracles themselves, but I'm not totally sure. What do you think about that?

I started moving the renaming to the oracles respectively, and the ripple effects are massive. In some cases, the FFI functions themselves now need the config object, and do nothing with it. But the signature of the trait impl has to change, because type_label now also takes the config object.

We do impl CodeType for CallbackInterfaceCodeType { for Python, which calls super::PythonCodeOracle.class_name(&self.id, config) and needs the config. Therefore the signature is changing. We have these side effects throughout the codebase.

So it seems cleaner to do it inside the Orcales, but how we implement the traits, it's currently not that straight forward. I would suggest to minimize the side effects in this PR and leave the renaming in the filter functions.

[mhammond]

Is there an actual use-case for this now? If not, it is starting look like experimenting with #2184 before landing this might make our future-selves less unhappy with our present-selves :) Another great thing about that is we could experiment with just one binding to understand how viable it is.

[gruberb]

Closing this, since this PR makes this work a lot easier: https://github.com/mozilla/uniffi-rs/pull/2191