Skip to content

Document (lack of) support for C++ exceptions #1172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mcgoo opened this issue Nov 30, 2017 · 4 comments · Fixed by #1209
Closed

Document (lack of) support for C++ exceptions #1172

mcgoo opened this issue Nov 30, 2017 · 4 comments · Fixed by #1209

Comments

@mcgoo
Copy link

mcgoo commented Nov 30, 2017

I couldn't find any reference to C++ exceptions in the docs. I assume this is because they are out of scope for bindgen? Am I right in assuming that any function that could emit an exception is unsafe to call directly from Rust code?

Relatedly, there seem to be a number of C++-specific pain points that could be reduced if bindgen could emit a C++ wrapper also. Ensuring the existence of out-of-line copies of inline functions, translating an exception to a Result<>, and instantiating templates, for example. Clearly doing so would add complexity to the build. Is that something that has been considered?

@emilio
Copy link
Contributor

emilio commented Dec 3, 2017

Am I right in assuming that any function that could emit an exception is unsafe to call directly from Rust code?

Yes, in the same way that panicking from a function called by FFI is unsafe.

Clearly doing so would add complexity to the build. Is that something that has been considered?

Not really, so far the C++ projects I've used bindgen on all disable exceptions. I thought exceptions were actually pretty marginal actually :).

If there's a use case yeah, handling it sounds reasonable, as long as there's a way to avoid the runtime overhead and such

@Ekleog
Copy link
Contributor

Ekleog commented Jan 2, 2018

In order to support exceptions, something like emitting a c++ wrapper that looks like this should work (and remove the need for handling compiler-specific mangling in bindgen, making it maybe more resilient to changes in the compilers) (syntax untested) :

extern "C"
result_original_type bindgen_mangled_function(arg_type arg) {
    try {
        return result_original_type_ok(original_cpp_function(arg));
    } catch (exception e) {
        return result_original_type_err(e.message());
    } catch (...) {
        return result_original_type_err("Unknown exception raised");
    }
}

This should have no runtime slowdown (c++ exceptions work completely out-of-path) for non-exception-raising paths apart from a single function call (and the wrapping the result in an Ok()-like structure).

Anyway, if exceptions could be added to “Unsupported Features” in https://rust-lang-nursery.github.io/rust-bindgen/cpp.html (maybe with a link to this issue) I think this would be great!

@fitzgen
Copy link
Member

fitzgen commented Jan 3, 2018

Anyway, if exceptions could be added to “Unsupported Features” in https://rust-lang-nursery.github.io/rust-bindgen/cpp.html (maybe with a link to this issue) I think this would be great!

I would be happy to r+ such a pull request :)

bors-servo pushed a commit that referenced this issue Jan 4, 2018
Mark C++ exceptions as unsupported in the book

This should close #1172 . It's my first contribution to the book, so I hope it's not too far from expected usage!
@fitzgen
Copy link
Member

fitzgen commented Jan 4, 2018

See #1208 for tracking implementation of trampoline helpers that catch exceptions.

Will leave this open for documenting exception support (or lack thereof).

@fitzgen fitzgen changed the title No commentary on C++ exception handling in docs? Document (lack of) support for C++ exceptions Jan 4, 2018
bors-servo pushed a commit that referenced this issue Jan 5, 2018
Mark C++ exceptions as unsupported in the book

This should close #1172 . It's my first contribution to the book, so I hope it's not too far from expected usage!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants