Generating Rust bindings which include a type named String doesn't compile

[DRvader]

Describe the bug
When trying to generate bindings to a type with the name String I get the error

Error:   × cxx couldn't handle our generated bindings - could be a bug in autocxx:
    │ unsupported unique_ptr target type

In my particular case the String type is being incidentally generated because it is being returned from another function. But it will reproduce when directly generating the type named String as well.

To Reproduce
I created a minimized example which reproduces this behaviour with a header named test.h

#pragma once

#include <memory>
#include <stdint.h>

namespace tester {
	struct String {
		char *data;
		uint32_t len;
	};
}

class Indirect {
public:
	tester::String data;

	std::unique_ptr<tester::String> datum() {
		return std::make_unique<tester::String>(data);
	}
};

use autocxx::prelude::*;

include_cpp! {
    #include "test.h"
    safety!(unsafe)
    generate!("Indirect")
}

fn main() {}

Additional notes
I did some initial digging and found that the cxxbridge that autocxx is generating contains

impl UniquePtr<String> {}
impl SharedPtr<String> {}
impl WeakPtr<String> {}
impl CxxVector<String> {}

without the corresponding type String = super::bindgen::root::tester::String; declaration (which appears later). If these lines are removed then compilation will fail with cxx0.h containing a function conversion which attempts to return a rust::String instead of tester::String.

I am happy to continue to explore/fix this problem, but I would like some guidance on where I should look to find the String -> rust::String conversion machinery.

[adetaylor]

Please file a test case PR following these instructions.

Unfortunately all the stuff around names in autocxx is very fragile so this might not be an easy fix.

[nujhong]

Added a test in #1402

I was able to create a simpler reproducible test case, I believe it's just name conflicts with the default prelude, using a different struct name other than String should generate bindings without problems

[b0o]

Is there a workaround for this if it's not possible to rename the String class we're binding to?

[b0o]

This is severely blocking progress for me and I haven't found a great workaround. I was able to write manual bindings for the String class in question, but I'm still having issues binding to classes which take or return Strings as arguments or return types.

I'm wondering if making it possible to specify an alternate name in the generate! macro call might be a workaround for cases like this, e.g. generate!("myns::String", "MyString"). Then, in the generated cxx::bridge, the original name could be specified with #[cxx_name = "String"].

[adetaylor]

I'd accept a PR to fix this. To be honest just having a PR which I can use to reproduce the problem in a test case might be enough for me to take a look. #1402 is the right sort of thing but I can't merge it due to the contributor not signing the (admittedly annoying) Google CLA.

There's a 50/50 chance that this is an easy fix, versus a bit of a nightmare which requires revisiting all the fragile naming stuff that I've been failing to rework for years.

[b0o]

I've actually just come up with a decent workaround by combining the following: manual bindings to my myns::String class using cxx, blocking autocxx from generating bindings with block!("myns::String"), and for some reason I needed to manually implement cxx::ExternType for one of my other autocxx-generated classes.

Now I'm able to generate other classes which have a few methods that accept/return myns::String. The other methods which accept/return "innocent" types are autogenerated properly, and I can manually bind to the myns::String-related methods using the cpp crate.

So, this is no longer urgent for me, although it would be nice it were fixed.

P.s. thank you Adrian for all of your hard work on this crate, in most cases it works spectacularly well and has saved me a ton of work!

[adetaylor]

Thanks - I'm glad you found a workaround.

As I mentioned, the naming stuff is annoyingly fragile, and unfortunately I think providing custom names for stuff falls into the category of "stuff I'm not quite brave enough to touch" until more work is done to clean it up - specifically a bunch of newtype wrappers for the different kinds of name we hold, which is roughly the thing tracked in #520.