Member names cannot be the same as their enclosing type

Right now it's possible for a generated C# struct/class to end up with a member that has the same name as the type itself. For example:

#[cs_bindgen]
#[derive(Clone, Copy)]
pub struct Foo {
    pub foo: String,
}

results in:

public struct Foo
{
    public string Foo;
}

which generates the error:

Compilation error: 'Foo': member names cannot be the same as their enclosing type

This can also happen with fields within enum variants (since enum variants are generated as structs when marshaled by value), and exported methods.

There are two main ways to address this:

Detect name conflicts automatically and apply some automatic mangling strategy to fix the error.
Allow users to change the name of the exported field, or skip exporting a field entirely, via an attribute on the Rust side.

These two solutions are not mutually exclusive either: We can attempt to automatically resolve conflicts, but defer to any user-specified naming. As a first pass, though, I'd like to not do the automatic conflict resolution. There's no way to automatically determine an appropriate alternative name, so this solution would involve some sort of mangling strategy such as prefixing the name with _, and I don't much like the idea of changing the name of items.

Ideally, we'd be able to emit a warning on the Rust side when we detect that a field/method name would cause a conflict on the C# side, however support for proc macros emitting warnings is not yet stable (see rust-lang/rust#54140). For now, I think our best bet is to generate an error on the Rust side when a conflict is detected, and we can later migrate to emitting a warning once doing so on stable is possible.

randomPoison / cs-bindgen

Member names cannot be the same as their enclosing type #60