Generated code from C++ headers does not compile

[Belval]

I am trying the wrap Microsoft's SEAL library

Input C/C++ Header

// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT license.

#pragma once

#include "seal/biguint.h"
#include "seal/ciphertext.h"
#include "seal/ckks.h"
#include "seal/context.h"
#include "seal/decryptor.h"
#include "seal/defaultparams.h"
#include "seal/encoder.h"
#include "seal/encryptionparams.h"
#include "seal/encryptor.h"
#include "seal/evaluator.h"
#include "seal/intarray.h"
#include "seal/keygenerator.h"
#include "seal/memorymanager.h"
#include "seal/plaintext.h"
#include "seal/batchencoder.h"
#include "seal/publickey.h"
#include "seal/randomgen.h"
#include "seal/relinkeys.h"
#include "seal/secretkey.h"
#include "seal/smallmodulus.h"

Yes this include other includes that impact reproduction of the bug BUT you can simply clone my project here and build it to get the error.

Bindgen Invocation

    // Generate the bindings
    let bindings = bindgen::Builder::default()
        .header("./seal/src/seal/seal.h")
        .clang_arg("-I./seal/src/")
        .clang_arg("-std=c++17")
        .clang_arg("-x")
        .clang_arg("c++")
        .opaque_type("std::*")
        .whitelist_type("seal::SEALContext")
        .whitelist_function("seal::SEALContext::Create")
        .generate()
        .expect("Unable to generate bindings");

Actual Results

^ expected `(`

See https://github.com/Belval/seal-rs/blob/master/src/bindings.rs for the generated binding.rs file

Expected Results

I just expected it to build and or provide a decent error message. In this case rustc simply can't compile it but I am not given any kind of hint as to what is wrong.

As a final note simply ask if you need anything else, I suppose I might be within the limits of the library when using C++ 17 but the documentation is unclear (at least to me) as to what is incompatible here.

[emilio]

So I couldn't build it, but rustc is pointing to the right location for the error, it's just that the file is in one massive line (since rustfmt cannot parse it either) and it basically covers the whole screen.

If you add a bunch of newlines the error points to:

pub fn std___shared_count___shared_count<_Lp>1 ( this : * mut u8 , __r : * mut u8 , arg1 : std_nothrow_t ) ; }

So this looks like a dupe of #1464. A test-case for it would be really amazing.

In any case, looks like your bindgen invocation is not doing what you think it's doing, you probably want:

@@ -57,7 +35,7 @@ fn main() {
         .clang_arg("-std=c++17")
         .clang_arg("-x")
         .clang_arg("c++")
-        .opaque_type("std::*")
+        .opaque_type("std::.*")
         .whitelist_type("seal::SEALContext")
         .whitelist_function("seal::SEALContext::Create")
         .generate()

So that the regex works as you expect.

[Belval]

I subscribed to the other issue, thank you for your help.

[Belval]

Also, sorry about the example not working, I had commented one too many line.

With std::.* the generated code works. Therefore I suppose that there was no issue afterall.

[Belval]

I cannot reopen the issue, but I am fairly sure that there is a real bug here.

Using the changes above, the bindings.rs file still has a undefined T value in IntArray:

#[repr(C)]
#[derive(Debug)]
pub struct seal_IntArray {
    pub pool_: seal_MemoryPoolHandle,
    pub capacity_: seal_IntArray_size_type,
    pub size_: seal_IntArray_size_type,
    pub data_: seal_util_Pointer<T>,
}

Which causes the expected compilation error:

error[E0412]: cannot find type `T` in this scope
    --> src/./bindings.rs:6218:34
     |
6218 |     pub data_: seal_util_Pointer<T>,
     |                                  ^ not found in this scope

For reference, here is the relevant header file.

For now, I have found that simply replacing T by u64 (since it's the only type they used as T in their code) works, but I am still puzzled as to how that could be expected behavior.

[emilio]

This is not expected behavior, but there's #1464 tracking this same problem, so it's pointless to have two different issues.

[Belval]

Isn't #1464 about bad indentation in the generated code? The initial issue was indeed similar to #1464 but the one I described in my previous comment does not seem to fall in that category.

[emilio]

#1464 it's not about bad indentation, but about a type being not correctly generated thinking that std___shared_count___shared_count<_Lp> is the type name (instead of just std___shared_count___shared_count). Your issue could or could not be the same, depending on whether we're failing to detect the template parameter altogether or we're failing to detect it's used.

But I agree it could be a different issue, mind opening a new one for that?

[Belval]

Done! Please tell me if you need anything else.