Skip to content
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

Explicitly instantiate function return values that are template classes #1024

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

scovich
Copy link
Contributor

@scovich scovich commented Nov 1, 2024

Following the ideas discussed in #402, search the set of referenced types for templates that are function return values and emit them all as fields of a dummy struct. This silences compiler warnings (clang/gcc) and errors (MSVC) about potential ABI compatibility issues caused by returning template classes by value from extern "C" functions. We take the dummy struct approach because explicit instantiation changes semantics of C++ templates and can cause linker errors if multiple compilation units do it -- not good for a general header file.

This behavior is implemented as a new pass (similar to the existing instantiate_monomorphs pass) that is controlled by a new export config, instantiate_return_value_monomorphs. The name of the dummy struct defaults to __cbindgen_return_value_monomorphs but can be overridden by a second config.

NOTE: The PR is large because of changes to tests and expected test output. Without that, the diff is much smaller:

10 files changed, 221 insertions(+), 19 deletions(-)

Fixes #402

@@ -144,9 +144,6 @@ fn compile(
command.arg("-Wno-attributes");
// clang warns about unused const variables.
command.arg("-Wno-unused-const-variable");
// clang also warns about returning non-instantiated templates (they could
// be specialized, but they're not so it's fine).
command.arg("-Wno-return-type-c-linkage");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer needed -- All tests that used to trigger this warning have been updated to use the new feature.

Comment on lines +1 to +3
// A stand-in for Box<T>, since Box<T> is undefined behavior in C++
#[repr(transparent)]
pub struct Foo<T> {
Copy link
Contributor Author

@scovich scovich Nov 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no way to compile C++ code that uses (opaque) Box<T>. At least, not without additional hacks that would trigger undefined behavior (such as manually providing a definition for the class).

This new feature ignores opaque items, which causes the test to fail compilation because of -Wreturn-type-c-linkage -Werror. If I change the feature to emit opaque items, compilation fails because the type lacks a definition.

I don't believe this test was specifically trying to test Box handling in the first place (and probably not even C++), so I updated it to use a transparent struct that will have the same behavior as Box in C code.

Or, we could just add the .skip_warning_as_error suffix to this test, if that's preferred.

println!("=== STDOUT ===\n{}", stdout);
println!("=== STDERR ===\n{}", stderr);
println!("==============");
assert!(out.status.success());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change wasn't strictly necessary, but it sure made debugging broken tests easier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support explicit template instantiation
1 participant