profile
viewpoint
Emilio Cobos Álvarez emilio @mozilla Berlin, Germany https://crisal.io

emilio/asm6809-boats 2

Juego de los barquitos en ensamblador, para computadores II

emilio/asm6809-matrix 2

Matrix multiplication in 6809 assembler

emilio/clang-format-merge 2

A git merge driver for clang-format.

emilio/base-blogger-template 1

Plantilla básica para blogger con un compilador incluído (en php)

emilio/bindgen-talk 1

https://www.meetup.com/Rust-Berlin/events/252872742/

ACM-USAL/taller-git 0

Contenidos para el taller de git

emilio/acm-sig-bot 0

Bot for ACM SIG groups

push eventrust-lang/rust-bindgen

Emilio Cobos Álvarez

commit sha 48808ed9d391fb90e5fdb5bf2223826eb5819e54

tests: Add a test for bool enum with an alias.

view details

Emilio Cobos Álvarez

commit sha 7f7809f779542ddb26643a5732ee945bf99e2537

codegen: Use shorthand initialization in EnumBuilder. This was introduced in #1850.

view details

push time in 2 hours

PR merged rust-lang/rust-bindgen

Enum improvement followups S-awaiting-review

These are two minor follow-ups to #1850.

+16 -2

0 comment

4 changed files

emilio

pr closed time in 2 hours

Pull request review commentrust-lang/rust-bindgen

Use absolute paths for unsaved files passed to clang and prepend -inc…

 fn test_multiple_header_calls_in_builder() {     } } +#[test]+fn test_multiple_header_contents() {+    let actual = builder()+        .header_contents("test.h", "int foo(const char* a);")+        .header_contents("test2.h", "float foo2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let (expected, _) = rustfmt(+        "extern \"C\" {+    pub fn foo2(b: *const ::std::os::raw::c_char) -> f32;+}+extern \"C\" {+    pub fn foo(a: *const ::std::os::raw::c_char) -> ::std::os::raw::c_int;+}+"+        .to_string(),+    );++    assert_eq!(expected, actual);+}++#[test]+fn test_mixed_header_and_header_contents() {+    let actual = builder()+        .header(concat!(+            env!("CARGO_MANIFEST_DIR"),+            "/tests/headers/func_ptr.h"+        ))+        .header(concat!(env!("CARGO_MANIFEST_DIR"), "/tests/headers/char.h"))+        .header_contents("test.h", "int bar(const char* a);")+        .header_contents("test2.h", "float bar2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let expected = include_str!(concat!(+        env!("CARGO_MANIFEST_DIR"),+        "/tests/expectations/tests/test_mixed_header_and_header_contents.rs"

That sounds great. as long as the first header doesn't have any anonymous enum or struct it should work.

curldivergence

comment created time in 3 hours

Pull request review commentrust-lang/rust-bindgen

Use absolute paths for unsaved files passed to clang and prepend -inc…

 fn test_multiple_header_calls_in_builder() {     } } +#[test]+fn test_multiple_header_contents() {+    let actual = builder()+        .header_contents("test.h", "int foo(const char* a);")+        .header_contents("test2.h", "float foo2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let (expected, _) = rustfmt(+        "extern \"C\" {+    pub fn foo2(b: *const ::std::os::raw::c_char) -> f32;+}+extern \"C\" {+    pub fn foo(a: *const ::std::os::raw::c_char) -> ::std::os::raw::c_int;+}+"+        .to_string(),+    );++    assert_eq!(expected, actual);+}++#[test]+fn test_mixed_header_and_header_contents() {+    let actual = builder()+        .header(concat!(+            env!("CARGO_MANIFEST_DIR"),+            "/tests/headers/func_ptr.h"+        ))+        .header(concat!(env!("CARGO_MANIFEST_DIR"), "/tests/headers/char.h"))+        .header_contents("test.h", "int bar(const char* a);")+        .header_contents("test2.h", "float bar2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let expected = include_str!(concat!(+        env!("CARGO_MANIFEST_DIR"),+        "/tests/expectations/tests/test_mixed_header_and_header_contents.rs"

Yeah, you're right that this pattern is not new, it's just worse having tests you need to manually update, because the overhead of updating them scales with the amount of tests :(

I guess we can take this as-is though.

curldivergence

comment created time in 3 hours

pull request commentrust-lang/rust-bindgen

Add --no-debug <regex> flag

I did that tweak and merged. Thanks!

varphone

comment created time in 4 hours

push eventrust-lang/rust-bindgen

Varphone Wong

commit sha ff3698189cb44f900e81d2b92131b1c191acf4de

Add --no-debug <regex> flag

view details

push time in 4 hours

PR merged rust-lang/rust-bindgen

Add --no-debug <regex> flag S-awaiting-review

This patch based on [Close #961] Add --no-debug <regex> flag #1190, thanks ivanovaleksey

Add --no-debug <regex> and Builder::no_debug(String) to supply regexes for matching against types that we should not derive or implement Debug for.

Adding this feature involves:

  • [x] Adding a new RegexSet member to bindgen::Builder (similar to the whitelisted_types set).
  • [x] A Builder method to add strings to that RegexSet.
  • [x] Plumbing in src/options.rs to convert --no-debug <regex> CLI flags into invocations of the builder method.
  • [x] Making the MonotoneFramework::constrain function in src/ir/analysis/derive_debug.rs check if the given item is explicitly marked not to be Debug, and if so, inserting it into the self.cannot_derive_debug set via return self.insert(id).
  • [x] Skipping any item explicitly marked not to be Debug in src/codegen/derive_debug.rs so that we don't generate an impl Debug for ... for these types when --impl-debug is passed.
  • [x] Tests!
    • [x] When --impl-debug is also supplied
    • [x] When --impl-debug is not also supplied
    • [x] When the no-debug type is transitively referenced by a whitelisted item
    • [x] When the no-debug type is explicitly whitelisted
    • [x] When the no-debug type is marked opaque
+216 -3

1 comment

16 changed files

varphone

pr closed time in 4 hours

push eventvarphone/rust-bindgen

Darren Kulp

commit sha 5678a142bce46de782d392f348bdc3541216e606

ci: Use llvm-5.0.1 to simplify target triple

view details

Darren Kulp

commit sha ed3ae0fcf60554ad3840ff5ec6970127622a2ca4

ci: Remove overrides for unsupported LLVM versions

view details

Darren Kulp

commit sha 5a638c0a11500e1e38fc9ab6dd4f5dab6681b4d4

ci: Explicitly select Ubuntu 16.04 (xenial) Xenial was being used anyway, but it is wise to be explicit. This lets us download a newer precompiled LLVM, too.

view details

Darren Kulp

commit sha 1f1766de4354bd8e4c7ff810e3abd6ceddb28b6b

ci: Remove extraneous variable declaration

view details

Cameron Mulhern

commit sha f56fbcef788098155a10ef455284e218fe15bc7a

Improves bindings for typed and anonymous enums

view details

Varphone Wong

commit sha 3c2813e972234d457d44e5cee74bba932682e1ee

Add --no-debug <regex> flag

view details

push time in 4 hours

pull request commentrust-lang/rust-bindgen

Added Bindgen names to objective-c pointer return types for #1835.

I rebased and addressed my nit, I'll merge once CI is back green. Thanks again for the fix!

simlay

comment created time in 4 hours

push eventsimlay/rust-bindgen

Darren Kulp

commit sha 5678a142bce46de782d392f348bdc3541216e606

ci: Use llvm-5.0.1 to simplify target triple

view details

Darren Kulp

commit sha ed3ae0fcf60554ad3840ff5ec6970127622a2ca4

ci: Remove overrides for unsupported LLVM versions

view details

Darren Kulp

commit sha 5a638c0a11500e1e38fc9ab6dd4f5dab6681b4d4

ci: Explicitly select Ubuntu 16.04 (xenial) Xenial was being used anyway, but it is wise to be explicit. This lets us download a newer precompiled LLVM, too.

view details

Darren Kulp

commit sha 1f1766de4354bd8e4c7ff810e3abd6ceddb28b6b

ci: Remove extraneous variable declaration

view details

Cameron Mulhern

commit sha f56fbcef788098155a10ef455284e218fe15bc7a

Improves bindings for typed and anonymous enums

view details

Sebastian Imlay

commit sha 22fa828121070391a724d3d484d6623d5e44d47b

Added Bindgen names to objective-c pointer return types * Took advantage of the repr transparent to use Bindgen return type names. * Updated unit tests and book

view details

push time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Added Bindgen names to objective-c pointer return types for #1835.

 impl TryToRustTy for Type {                  let inner =                     inner.into_resolver().through_type_refs().resolve(ctx);+                let is_objc_pointer = if let Some(ty) = inner.kind().as_type() {

nit: Use map_or(false? But actually this should be moved down where we have inner_ty, which is basically inner unwrapped to a type.

simlay

comment created time in 4 hours

PR opened rust-lang/rust-bindgen

Enum improvement followups

These are two minor follow-ups to #1850.

+16 -2

0 comment

4 changed files

pr created time in 4 hours

create barnchrust-lang/rust-bindgen

branch : enum-improvement-followups

created branch time in 4 hours

push eventrust-lang/rust-bindgen

Cameron Mulhern

commit sha f56fbcef788098155a10ef455284e218fe15bc7a

Improves bindings for typed and anonymous enums

view details

push time in 4 hours

PR merged rust-lang/rust-bindgen

Improves bindings for typed and anonymous enums S-awaiting-review

This PR resolves issues outlined in #1828. Specifically:

  1. Unnamed enums will generate constant bindings of the underlying type.
  2. Named enums will continue to generate constant bindings with the enum name as the underlying type.
  3. The enum name type alias generated for constant bindings of named enums will use the rust type name of the underlying type, not its rust integer representation.
+147 -82

0 comment

37 changed files

csmulhern

pr closed time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Improves bindings for typed and anonymous enums

 impl<'a> EnumBuilder<'a> {                 }             } -            EnumVariation::Consts => EnumBuilder::Consts {-                variants: vec![quote! {-                    #( #attrs )*-                    pub type #ident = #repr;-                }],-                codegen_depth: enum_codegen_depth,-            },+            EnumVariation::Consts => {+                let mut variants = Vec::new();++                if is_ty_named {+                    variants.push(quote! {+                        #( #attrs )*+                        pub type #ident = #repr;+                    });+                }++                EnumBuilder::Consts {+                    repr: repr,

Well, actually it's little effort, and I want to add another test too, so I can do this after merging.

Thank you so much for the patch!

csmulhern

comment created time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Improves bindings for typed and anonymous enums

 impl<'a> EnumBuilder<'a> {                 }             } -            EnumVariation::Consts => EnumBuilder::Consts {-                variants: vec![quote! {-                    #( #attrs )*-                    pub type #ident = #repr;-                }],-                codegen_depth: enum_codegen_depth,-            },+            EnumVariation::Consts => {+                let mut variants = Vec::new();++                if is_ty_named {+                    variants.push(quote! {+                        #( #attrs )*+                        pub type #ident = #repr;+                    });+                }++                EnumBuilder::Consts {+                    repr: repr,

nit: use the shorthand notation? repr, variants,

csmulhern

comment created time in 4 hours

push eventrust-lang/rust-bindgen

Darren Kulp

commit sha 5678a142bce46de782d392f348bdc3541216e606

ci: Use llvm-5.0.1 to simplify target triple

view details

Darren Kulp

commit sha ed3ae0fcf60554ad3840ff5ec6970127622a2ca4

ci: Remove overrides for unsupported LLVM versions

view details

Darren Kulp

commit sha 5a638c0a11500e1e38fc9ab6dd4f5dab6681b4d4

ci: Explicitly select Ubuntu 16.04 (xenial) Xenial was being used anyway, but it is wise to be explicit. This lets us download a newer precompiled LLVM, too.

view details

Darren Kulp

commit sha 1f1766de4354bd8e4c7ff810e3abd6ceddb28b6b

ci: Remove extraneous variable declaration

view details

push time in 4 hours

PR merged rust-lang/rust-bindgen

ci: Explicitly use Ubuntu 16.04 S-awaiting-review

Since Ubuntu 16.04 LTS builds of LLVM are available for each major libclang version supported by bindgen, it could be worthwhile to point to those instead of Ubuntu 14.04 as before.

For LLVM 10.0.0, Ubuntu builds are available for only 18.04, so the current PR might help to prepare for that transition later.

Using LLVM 5.0.1 instead of 5.0.0 avoids the target-triple mixup that needed a special case for 5.0.0.

+4 -10

0 comment

2 changed files

kulp

pr closed time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Add --no-debug <regex> flag

++/** <div rustbindgen nodebug></div> */+template<typename T>+class CopiableButWait {

This name seems copy-pasted, but inaccurate for this test, mind fixing it?

varphone

comment created time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Use absolute paths for unsaved files passed to clang and prepend -inc…

 fn test_multiple_header_calls_in_builder() {     } } +#[test]+fn test_multiple_header_contents() {+    let actual = builder()+        .header_contents("test.h", "int foo(const char* a);")+        .header_contents("test2.h", "float foo2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let (expected, _) = rustfmt(+        "extern \"C\" {+    pub fn foo2(b: *const ::std::os::raw::c_char) -> f32;+}+extern \"C\" {+    pub fn foo(a: *const ::std::os::raw::c_char) -> ::std::os::raw::c_int;+}+"+        .to_string(),+    );++    assert_eq!(expected, actual);+}++#[test]+fn test_mixed_header_and_header_contents() {+    let actual = builder()+        .header(concat!(+            env!("CARGO_MANIFEST_DIR"),+            "/tests/headers/func_ptr.h"+        ))+        .header(concat!(env!("CARGO_MANIFEST_DIR"), "/tests/headers/char.h"))+        .header_contents("test.h", "int bar(const char* a);")+        .header_contents("test2.h", "float bar2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let expected = include_str!(concat!(+        env!("CARGO_MANIFEST_DIR"),+        "/tests/expectations/tests/test_mixed_header_and_header_contents.rs"

Hmm, how do you update this file when output changes? Do you need to do that manually? If so, it's a bit unfortunate.

curldivergence

comment created time in 4 hours

Pull request review commentrust-lang/rust-bindgen

Use absolute paths for unsaved files passed to clang and prepend -inc…

 fn test_multiple_header_calls_in_builder() {     } } +#[test]+fn test_multiple_header_contents() {+    let actual = builder()+        .header_contents("test.h", "int foo(const char* a);")+        .header_contents("test2.h", "float foo2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let (expected, _) = rustfmt(+        "extern \"C\" {+    pub fn foo2(b: *const ::std::os::raw::c_char) -> f32;+}+extern \"C\" {+    pub fn foo(a: *const ::std::os::raw::c_char) -> ::std::os::raw::c_int;+}+"+        .to_string(),+    );++    assert_eq!(expected, actual);+}++#[test]+fn test_mixed_header_and_header_contents() {+    let actual = builder()+        .header(concat!(+            env!("CARGO_MANIFEST_DIR"),+            "/tests/headers/func_ptr.h"+        ))+        .header(concat!(env!("CARGO_MANIFEST_DIR"), "/tests/headers/char.h"))+        .header_contents("test.h", "int bar(const char* a);")+        .header_contents("test2.h", "float bar2(const char* b);")+        .clang_arg("--target=x86_64-unknown-linux")+        .generate()+        .unwrap()+        .to_string();++    let (actual, stderr) = rustfmt(actual);+    println!("{}", stderr);++    let expected = include_str!(concat!(+        env!("CARGO_MANIFEST_DIR"),+        "/tests/expectations/tests/test_mixed_header_and_header_contents.rs"+    ));+    let (expected, _) = rustfmt(expected.to_string());++    assert_eq!(expected, actual);+}++

You need to remove this stray newline for CI to pass.

curldivergence

comment created time in 4 hours

issue commentmozilla/standards-positions

Make system color keywords compute to themselves

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1112362 too, which I think it's a bug with Blink's implementation.

kbabbitt

comment created time in 5 hours

issue commentmozilla/standards-positions

Make system color keywords compute to themselves

I think this change is generally ok, but my main concern is about how is interpolation defined, which we left as a TBD during the CSSWG resolution and to my knowledge it hasn't been defined yet.

Do the system colors get resolved when they get interpolated? If not, how does the computed value look like? Do we just interpolate discretely when you hit a system color?

Ideally I think this should be defined before shipping it.

kbabbitt

comment created time in 5 hours

Pull request review commentrust-lang/rust-bindgen

Add --anon-fields-prefix option

 where                 .takes_value(true),             Arg::with_name("anon-fields-prefix")                 .long("anon-fields-prefix")-                .help(-                    "Use the given prefix for the anon fields instead of \-                     __bindgen_anon_.",-                )+                .help("Use the given prefix for the anon fields.")                 .value_name("prefix")+                .default_value("__bindgen_anon_")

Moving this to a constant so that we don't duplicate this would also be useful.

varphone

comment created time in 10 hours

Pull request review commentrust-lang/rust-bindgen

Add --anon-fields-prefix option

 impl Builder {             output_vector.push(prefix.clone());         } -        if let Some(ref prefix) = self.options.anon_fields_prefix {+        if let prefix = &self.options.anon_fields_prefix {

Easiest one IMO is moving the default prefix to a constant, and just do:

if self.options.anon_fields_prefix != DEFAULT_ANON_FIELDS_PREFIX {
    output_vector.push(...);
}

Either that, or using Option<>, or using a String and treating the empty string as a default (as there can't be any use cases for an empty prefix because otherwise we'd generate invalid code I think) work for me.

varphone

comment created time in 10 hours

create barnchemilio/online-probabilistic-load-forecasting

branch : py3

created branch time in 2 days

issue commentrust-lang/rust-bindgen

`.clang_arg("-x c++")` causes failure in `generate`

Yes, we really need to document this clearly. We could make clang_arg more auto-magical I guess, but that breaks paths with spaces and so on, so not a fan.

@kulp's suggestions are great. Suggesting --language=c++ is probably also ok if libclang supports it (it probably does).

kulp

comment created time in 3 days

issue commenteqrion/cbindgen

double negative for i64 min value with i64 suffix

Great, thanks for checking!

comicfans

comment created time in 3 days

delete branch mozsearch/mozsearch

delete branch : provision-fix

delete time in 3 days

PR closed mozsearch/mozsearch

Reviewers
Fix re-provisioning.

If that directory exists already and you run vagrant provision, then the provisioning script errors which is bad.

+1 -0

4 comments

1 changed file

emilio

pr closed time in 3 days

push eventfiji-flo/bikeshed-rs

whichxjy

commit sha 2ba5014bd683ca3c5c72cb21e7a4d6d2a1ff82eb

Add references section

view details

whichxjy

commit sha fae173116b2e0f6691fc6d58120cb9a3721075d7

Add index section

view details

whichxjy

commit sha 3402691bd91e0c1c0ae727e047f481c17b541950

Add panel

view details

whichxjy

commit sha 712b97f96c60fd8b63a9828b1c30118178d5459a

Simplify container-getter

view details

push time in 3 days

PR merged fiji-flo/bikeshed-rs

Add references section

This PR adds references section for dfn autolinks.

+254 -33

0 comment

6 changed files

whichxjy

pr closed time in 3 days

push eventeqrion/cbindgen

Kartikaya Gupta

commit sha 977d95b0ff3ce586cb768de12cb375370be0992d

Add failing scenario to test A u32 bitflags structure should allow a 1<<31 value. However, with current cbindgen this produces a compiler error with latest clang, because 1<<31 is treated as a signed value (-2147483648) which cannot be narrowed back into a uint32_t without a cast.

view details

Emilio Cobos Álvarez

commit sha f41eefba459b6d6e4dc56f1ef6dacb8a2efcf24e

Add fix for failing scenario This fixes the scenario by adding an explicit cast based on type of the field. Fixes #555

view details

Emilio Cobos Álvarez

commit sha 3527e0f1e3c4e8da4f235166b36cb093c2018af6

Update expectation files

view details

push time in 3 days

PR merged eqrion/cbindgen

Allow 1<<31 as a bitflags value

Fixes #555

+173 -83

8 comments

16 changed files

staktrace

pr closed time in 3 days

issue closedeqrion/cbindgen

Running cbindgen on a u32 bitflag with a 1<<31 entry produces C++ code that doesn't compile

Assuming you have a setup where cargo +nightly test passes everything, apply this patch:

diff --git a/tests/rust/bitflags.rs b/tests/rust/bitflags.rs
index 6c3fe4e..017104a 100644
--- a/tests/rust/bitflags.rs
+++ b/tests/rust/bitflags.rs
@@ -13,10 +13,18 @@ bitflags! {
         const START = 1 << 1;
         /// 'end'
         const END = 1 << 2;
         /// 'flex-start'
         const FLEX_START = 1 << 3;
     }
 }
 
+bitflags! {
+    #[repr(C)]
+    pub struct DebugFlags: u32 {
+        /// Flag with the topmost bit set of the u32
+        const BIGGEST_ALLOWED = 1 << 31;
+    }
+}
+
 #[no_mangle]
-pub extern "C" fn root(flags: AlignFlags) {}
+pub extern "C" fn root(flags: AlignFlags, bigger_flags: DebugFlags) {}

and run the tests. For me there's this failure:

Running: "/home/kats/.mozbuild/clang/bin/clang++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/bitflags.cpp" "-o" "/home/kats/tmp/cbindgen-test-outputWsIxRN/bitflags.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-Wno-deprecated" "-Wno-unused-const-variable" "-Wno-return-type-c-linkage"
thread 'test_bitflags' panicked at 'Output failed to compile: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "/home/kats/zspace/cbindgen/tests/expectations/bitflags.cpp:83:80: error: constant expression evaluates to -2147483648 which cannot be narrowed to type \'uint32_t\' (aka \'unsigned int\') [-Wc++11-narrowing]\nstatic const DebugFlags DebugFlags_BIGGEST_ALLOWED = DebugFlags{ /* .bits = */ (1 << 31) };\n                                                                               ^~~~~~~~~\n/home/kats/zspace/cbindgen/tests/expectations/bitflags.cpp:83:80: note: insert an explicit cast to silence this issue\nstatic const DebugFlags DebugFlags_BIGGEST_ALLOWED = DebugFlags{ /* .bits = */ (1 << 31) };\n                                                                               ^~~~~~~~~\n                                                                               static_cast<uint32_t>( )\n1 error generated.\n" }', tests/tests.rs:118:5

closed time in 3 days

staktrace

pull request commenteqrion/cbindgen

Allow 1<<31 as a bitflags value

Ugh, that really kinda sucks. It sucks more that there's literally no warning for this in the simple case... But well this is a bit better than what we're doing now, and it fixes @staktrace's case since we compile with C++17 in mozilla-central.

And users of cbindgen can also add a cast where appropriate to cause the behavior to be properly defined. Thanks for tweaking the patch @staktrace! This looks ok to me.

staktrace

comment created time in 3 days

issue commenteqrion/cbindgen

Support for self-referencing types?

Yes, I agree that this is a cbindgen bug.

kvark

comment created time in 3 days

issue closedeqrion/cbindgen

A better error message for unsupported unnamed parameters

cbindgen gives the "Parameter has an unsupported type" error for the following code:

use std::os::raw::c_char;

#[no_mangle]
pub extern "C" fn foo(_: c_char) {
    todo!()
}

The command that I used to generate the header:

cbindgen --config cbindgen.toml --crate bt --output my_header.h --lang c

I have spent some time trying to understand what was wrong with c_char (libc::c_char), till I figured that I should give a name to this parameter.

closed time in 3 days

DarkEld3r

issue commenteqrion/cbindgen

A better error message for unsupported unnamed parameters

Huh, I somehow re-discovered this bug while doing some refactoring, it's fixed in master via https://github.com/eqrion/cbindgen/pull/550.

DarkEld3r

comment created time in 3 days

issue commenteqrion/cbindgen

Support for constant byte literal

Yeah, this shouldn't be terrible to add I think, wanna give it a shot? I'm happy to help out.

Seems like generating a const uint8_t[] should be the most straight-forward implementation unless I'm missing something.

Wodann

comment created time in 3 days

issue closedeqrion/cbindgen

install error

There was an error When execute cargo install --force cbindgen 。

Updating crates.io index error: failed to download cbindgen v0.14.3

Caused by: failed to enable HTTP2, is curl not built right?

Caused by: [1] Unsupported protocol

closed time in 3 days

liuqi-sun

issue commenteqrion/cbindgen

install error

Closing for now because this doesn't look like a cbindgen issue and I got no reply, but please reopen if it turns out to be.

liuqi-sun

comment created time in 3 days

issue commenteqrion/cbindgen

double negative for i64 min value with i64 suffix

Hmmm. This was intended to be fixed in https://github.com/eqrion/cbindgen/pull/490 which is in that release... Can you check in master anyhow and confirm it's fixed there?

comicfans

comment created time in 3 days

issue closedrust-lang/rust-bindgen

Unable to compile bindgen libraries for ESP32

Actual Results

          /home/fred/xtensa-rust-quickstart/target/xtensa-esp32-none-elf/debug/deps/esp32-8ad70c7d5337caba.esp32.66tnvxh8-cgu.0.rcgu.o:(.literal.main+0x14): undefined reference to `uart_param_config'
          /home/fred/xtensa-rust-quickstart/target/xtensa-esp32-none-elf/debug/deps/esp32-8ad70c7d5337caba.esp32.66tnvxh8-cgu.0.rcgu.o:(.literal.main+0x18): undefined reference to `uart_set_pin'
          /home/fred/xtensa-rust-quickstart/target/xtensa-esp32-none-elf/debug/deps/esp32-8ad70c7d5337caba.esp32.66tnvxh8-cgu.0.rcgu.o:(.literal.main+0x20): undefined reference to `uart_driver_install'
          /home/fred/xtensa-rust-quickstart/target/xtensa-esp32-none-elf/debug/deps/esp32-8ad70c7d5337caba.esp32.66tnvxh8-cgu.0.rcgu.o:(.literal.main+0x3c): undefined reference to `uart_write_bytes'
          collect2: error: ld returned 1 exit status

Expected Results

Hi I'm using bindgen libraries generated to use peripheral functions, such as printing to the serial bus for the ESP32 board and I'm getting the error above when compiling with xargo build. Any ideas as to what would prevent it from seeing the .h file that has the functions defined?

The library is from the following location: https://github.com/lexxvir/esp32-hello

When I try to build the original repo I get the following error, Im not sure if they are related

Actual Results from Original repo

/home/fred/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: cannot open linker script file esp32_out.ld: No such file or directory
          collect2: error: ld returned 1 exit status


When I don't include the binding files I am able to compile and flash

closed time in 3 days

fmc5046

issue commentrust-lang/rust-bindgen

Unable to compile bindgen libraries for ESP32

If you don't call the functions, then you don't get the linker errors, but that is expected, because rustc doesn't end up calling them. The second error may be related in the sense that it's a linker script that could potentially define those functions.

I think you should file an issue in https://github.com/MabezDev/xtensa-rust-quickstart instead, I don't think this is actionable from bindgen. Bindgen is just a text-to-text tool effectively, and seems to be working fine in your example.

But let me know if you disagree, or there's something we could improve here, and reopen if so. Thank you!

fmc5046

comment created time in 3 days

issue commentrust-lang/rust-bindgen

Unable to compile bindgen libraries for ESP32

So those are all linker errors, which means that rustc is calling functions that are not defined in the final binary.

You need to figure out where are those symbols supposed to be defined, but bindgen doesn't take care of linking or anything like that, so I suspect the error is somewhere else.

fmc5046

comment created time in 3 days

issue closedrust-lang/rust-bindgen

bindgen takes like a minute per C++ struct & produces gigabytes of log output with debug logging enabled

<!-- Thanks for filing a bindgen issue! We appreciate it :-) -->

Input C/C++ Header

wxWidgets header files. The complete set is about 12 MB in size, but I am only doing wx/aboutdlg.h. But they are actually C++ header files, so I #include it from a wrapper.hpp file.

Bindgen Invocation

	let bindings = bindgen::Builder::default()
		.header("wrapper.hpp")
		.detect_include_paths(false)
		.clang_args(cxx_flags)
		.parse_callbacks(Box::new(bindgen::CargoCallbacks))
		.whitelist_type("wx.*")
		.opaque_type("std::.*")
		.generate()
		.expect("Couldn't make bindings!");

Actual Results

After each struct found, for example this: image

bindgen doesn't output anything for about a minute. It does this for every struct in the program. After the minute wait, here is how much output it produces for one struct:

bindgen

It's so large, it doesn't even fit in CLion's scrollback buffer.

Here is how much memory the cargo process takes up after about 30 minutes of bindgen taking forever to chew through wx/aboutdlg.h:

image

This causes my kernel's OOM killer to go mad and start killing things that probably should not be killed.

closed time in 3 days

LoganDark

issue commentrust-lang/rust-bindgen

bindgen takes like a minute per C++ struct & produces gigabytes of log output with debug logging enabled

Right... I think this is wontfix for now. Improvements to make verbose logging equally useful but more compact are welcome of course, but... :)

LoganDark

comment created time in 3 days

issue commentrust-lang/rust-bindgen

bindgen shouldn't generate f32

What is the issue that you're hitting with harfbuzz? It's likely that's unrelated if you're in any sort of "common" platform.

jdm

comment created time in 3 days

issue commentrust-lang/rust-bindgen

bindgen shouldn't generate f32

@jdm curious, what platform are you on that has floats that aren't f32?

It's technically a bug, but not really something that I'd expect to come up with any sort of frequency.

jdm

comment created time in 3 days

issue commentrust-lang/rust-bindgen

Multidimensional array binding has incorrect mutability.

Hmm, I'd look at similar issues like #1727 and such. https://github.com/rust-lang/rust-bindgen/commit/e09602bb8ba690c0caf317c7eb9fe4462a68bd84 is the fix for that, maybe we're missing a similar check in the code that parses arrays. Though I'd first double-check that that is what the C compiler is doing.

Thanks for filing this!

jbangelo

comment created time in 3 days

issue commentrust-lang/rust-bindgen

Panic with 'Unable to get layout information?'

Thanks for the reduced test-case, that's awesome! Yeah, that should be considered a forward declaration but it's not, that is very odd.

virtualritz

comment created time in 3 days

delete branch eqrion/cbindgen

delete branch : clang-test

delete time in 3 days

push eventeqrion/cbindgen

Emilio Cobos Álvarez

commit sha 6ba31b49f445290a4ac1d3141f2a783306b23a88

tests: Fix errors when testing with clang. Fixes #554

view details

push time in 3 days

PR merged eqrion/cbindgen

tests: Fix errors when testing with clang.

Fixes #554

+10 -2

0 comment

1 changed file

emilio

pr closed time in 3 days

issue closedeqrion/cbindgen

Tests fail due to C++ compilation error

I checked out the repo and ran cargo +nightly test. Two tests failed (output below). g++ --version says it's 5.5.0-12ubunutu1~16.04)

failures:

---- test_associated_in_body stdout ----
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "type" "-o" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TYPE"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_TYPE"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "type" "-o" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TYPE"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "tag" "-o" "/home/kats/zspace/cbindgen/tests/expectations/tag/associated_in_body.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TAG"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_TAG"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "tag" "-o" "/home/kats/zspace/cbindgen/tests/expectations/tag/associated_in_body.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/associated_in_body.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TAG"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "both" "-o" "/home/kats/zspace/cbindgen/tests/expectations/both/associated_in_body.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_BOTH"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/associated_in_body.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_BOTH"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "both" "-o" "/home/kats/zspace/cbindgen/tests/expectations/both/associated_in_body.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/associated_in_body.c" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_BOTH"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "-o" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp" "--config" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.toml" "/home/kats/zspace/cbindgen/tests/rust/associated_in_body.rs"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp" "-o" "/home/kats/tmp/cbindgen-test-outputiRwLsY/associated_in_body.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17"
thread 'test_associated_in_body' panicked at 'Output failed to compile: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp:46:47: error: ‘StyleAlignFlags::AUTO’ declared as an ‘inline’ variable\n inline const StyleAlignFlags StyleAlignFlags::AUTO = StyleAlignFlags{ /* .bits = */ 0 };\n                                               ^\n/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp:48:47: error: ‘StyleAlignFlags::NORMAL’ declared as an ‘inline’ variable\n inline const StyleAlignFlags StyleAlignFlags::NORMAL = StyleAlignFlags{ /* .bits = */ 1 };\n                                               ^\n/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp:50:47: error: ‘StyleAlignFlags::START’ declared as an ‘inline’ variable\n inline const StyleAlignFlags StyleAlignFlags::START = StyleAlignFlags{ /* .bits = */ (1 << 1) };\n                                               ^\n/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp:52:47: error: ‘StyleAlignFlags::END’ declared as an ‘inline’ variable\n inline const StyleAlignFlags StyleAlignFlags::END = StyleAlignFlags{ /* .bits = */ (1 << 2) };\n                                               ^\n/home/kats/zspace/cbindgen/tests/expectations/associated_in_body.cpp:54:47: error: ‘StyleAlignFlags::FLEX_START’ declared as an ‘inline’ variable\n inline const StyleAlignFlags StyleAlignFlags::FLEX_START = StyleAlignFlags{ /* .bits = */ (1 << 3) };\n                                               ^\n" }', tests/tests.rs:118:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- test_constant_constexpr stdout ----
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "type" "-o" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TYPE"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_TYPE"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "type" "-o" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TYPE"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "tag" "-o" "/home/kats/zspace/cbindgen/tests/expectations/tag/constant_constexpr.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TAG"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_TAG"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "tag" "-o" "/home/kats/zspace/cbindgen/tests/expectations/tag/constant_constexpr.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/tag/constant_constexpr.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_TAG"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--cpp-compat" "--style" "both" "-o" "/home/kats/zspace/cbindgen/tests/expectations/both/constant_constexpr.compat.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_BOTH"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/constant_constexpr.compat.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.compat.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17" "-D" "CBINDGEN_STYLE_BOTH"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "--lang" "c" "--style" "both" "-o" "/home/kats/zspace/cbindgen/tests/expectations/both/constant_constexpr.c" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "gcc" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/both/constant_constexpr.c" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-D" "CBINDGEN_STYLE_BOTH"
Running: "/home/kats/zspace/cbindgen/target/debug/cbindgen" "-o" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.cpp" "--config" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.toml" "/home/kats/zspace/cbindgen/tests/rust/constant_constexpr.rs"
Running: "g++" "-D" "DEFINED" "-c" "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.cpp" "-o" "/home/kats/tmp/cbindgen-test-outputTOOZtd/constant_constexpr.o" "-I" "/home/kats/zspace/cbindgen/tests" "-Wall" "-Werror" "-Wno-attributes" "-std=c++17"
thread 'test_constant_constexpr' panicked at 'Output failed to compile: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "/home/kats/zspace/cbindgen/tests/expectations/constant_constexpr.cpp:18:37: error: ‘Foo::CONSTANT_I64_BODY’ declared as an ‘inline’ variable\n constexpr inline const int64_t Foo::CONSTANT_I64_BODY = 216;\n                                     ^\n" }', tests/tests.rs:118:5


failures:
    test_associated_in_body
    test_constant_constexpr

test result: FAILED. 104 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out

closed time in 3 days

staktrace

PR opened eqrion/cbindgen

tests: Fix errors when testing with clang.

Fixes #554

+10 -2

0 comment

1 changed file

pr created time in 3 days

push eventeqrion/cbindgen

Emilio Cobos Álvarez

commit sha 398b631e1d3f90ccab7ef79eca72e49c147dd9d2

tests: Fix errors when testing with clang. Fixes #554

view details

push time in 3 days

create barncheqrion/cbindgen

branch : clang-test

created branch time in 3 days

issue commenteqrion/cbindgen

double negative for i64 min value with i64 suffix

Hmm, what version are you testing with? For the first example I get the following on master:

static const int64_t value = -9223372036854775808ULL;

Which seems about right. i64::MIN is not expected to work, for the reason you mention, cbindgen is a bit dumb dumb, see #214 etc :)

comicfans

comment created time in 3 days

pull request commenteqrion/cbindgen

Allow 1<<31 as a bitflags value

Something that is UB would be:

uint64_t FOO = (1 << 32);

Which I guess is also an issue for rust bitflags, as the equivalent rust code does compile just fine. You need to insert a rust cast for this to behave correctly which is unfortunate: pub const FOO: u64 = (1 as u64) << 33;

But well that does warn loudly, so there's that...

staktrace

comment created time in 3 days

issue commenteqrion/cbindgen

Running cbindgen on a u32 bitflag with a 1<<31 entry produces C++ code that doesn't compile

FWIW, immediate workaround available is to do (1 as u32 << 31), if you don't want to deal with updating cbindgen and such.

staktrace

comment created time in 3 days

pull request commenteqrion/cbindgen

Allow 1<<31 as a bitflags value

Hmm, so... Do we need this cast in C mode?

If so, we may want something like this instead (it also generates sligthly nicer code IMO, wdyt @staktrace?):

diff --git a/src/bindgen/bitflags.rs b/src/bindgen/bitflags.rs
index 6c89622..cc1a4cb 100644
--- a/src/bindgen/bitflags.rs
+++ b/src/bindgen/bitflags.rs
@@ -43,7 +43,7 @@ impl Bitflags {
             }
         };
 
-        let consts = flags.expand(name);
+        let consts = flags.expand(name, repr);
         let impl_ = parse_quote! {
             impl #name {
                 #consts
@@ -81,7 +81,7 @@ struct Flag {
 }
 
 impl Flag {
-    fn expand(&self, struct_name: &syn::Ident) -> TokenStream {
+    fn expand(&self, struct_name: &syn::Ident, repr: &syn::Type) -> TokenStream {
         let Flag {
             ref attrs,
             ref name,
@@ -90,7 +90,7 @@ impl Flag {
         } = *self;
         quote! {
             #(#attrs)*
-            pub const #name : #struct_name = #struct_name { bits: #value };
+            pub const #name : #struct_name = #struct_name { bits: (#value) as #repr };
         }
     }
 }
@@ -124,10 +124,10 @@ impl Parse for Flags {
 }
 
 impl Flags {
-    fn expand(&self, struct_name: &syn::Ident) -> TokenStream {
+    fn expand(&self, struct_name: &syn::Ident, repr: &syn::Type) -> TokenStream {
         let mut ts = quote! {};
         for flag in &self.0 {
-            ts.extend(flag.expand(struct_name));
+            ts.extend(flag.expand(struct_name, repr));
         }
         ts
     }

Also, question for @froydnj: Is it really UB? Or only "implementation defined" (which is well defined if you assume two's complement?). I'm surprised something so simple wouldn't warn with Wpedantic if it was UB, but...

A funny consequence of this patch is that now nested struct expressions look really funny:

#[repr(C)]
pub struct Bar {
    baz: u32,
}

#[repr(C)]
pub struct Foo {
    bar: Bar,
}

pub const FOO: Foo = Foo { bar: Bar { baz: 3 } };

generates:

static const Foo FOO = Foo{ /* .bar = */ static_cast<decltype(Foo::bar)>(Bar{ /* .baz = */ static_cast<decltype(Bar::baz)>(3) }) };

Which is ugly but compiles, turns out (wasn't sure whether you could static-cast structs). Maybe the bitflags-scoped fix is slightly less invasive.

staktrace

comment created time in 3 days

pull request commenteqrion/cbindgen

Allow 1<<31 as a bitflags value

I need to take a closer look, that being said, it baffles me a bit that static const uint32_t CONST = (1 << 31); doesn't warn, but static const Foo FOO = Foo { (1 << 31) }; does.

staktrace

comment created time in 3 days

Pull request review commentfiji-flo/bikeshed-rs

Add references section

 pub fn fill_toc_section(doc: &mut Spec) {                         },                     );                     span_el.append(html::new_text(-                        html::get_attr(&heading_el, "data-level").unwrap(),+                        html::get_attr(&heading_el, "data-level").unwrap_or_else(|| "".to_owned()),

unwrap_or_default()

whichxjy

comment created time in 4 days

Pull request review commentfiji-flo/bikeshed-rs

Add references section

 pub fn fill_abstract_section(doc: &mut Spec) {     } } +pub fn add_references_section(doc: &mut Spec) {+    if doc.link_texts.is_empty() {+        return;+    }++    let container = match get_container_or_body(doc, "references") {+        Some(container) => container,+        None => return,+    };++    let h2_el = html::new_element(+        "h2",+        btreemap! {+            "class" => "no-num no-ref",+            "id" => "references",++        },+    );+    h2_el.append(html::new_text("References"));+    container.append(h2_el);++    if !doc.link_texts.is_empty() {+        let h3_el = html::new_element(+            "h3",+            btreemap! {+                "class" => "no-num no-ref",+                "id" => "normative",+

same here.

whichxjy

comment created time in 4 days

Pull request review commentfiji-flo/bikeshed-rs

Add references section

 pub fn fill_abstract_section(doc: &mut Spec) {     } } +pub fn add_references_section(doc: &mut Spec) {+    if doc.link_texts.is_empty() {+        return;+    }++    let container = match get_container_or_body(doc, "references") {+        Some(container) => container,+        None => return,+    };++    let h2_el = html::new_element(+        "h2",+        btreemap! {+            "class" => "no-num no-ref",+            "id" => "references",+

nit: Stray newline.

whichxjy

comment created time in 4 days

Pull request review commentfiji-flo/bikeshed-rs

Add references section

 fn get_container_or_head(doc: &Spec, tag: &str) -> Option<NodeRef> {         .or_else(|| Some(doc.head().clone())) } +fn get_container_or_body(doc: &Spec, tag: &str) -> Option<NodeRef> {+    if !doc.md.boilerplate.get(tag) {+        return None;+    }++    doc.containers

It seems this could return Option<&NodeRef> and avoid the two clones.

whichxjy

comment created time in 4 days

PR opened mozsearch/mozsearch

Fix re-provisioning.

If that directory exists already and you run vagrant provision, then the provisioning script errors which is bad.

+1 -0

0 comment

1 changed file

pr created time in 5 days

create barnchmozsearch/mozsearch

branch : provision-fix

created branch time in 5 days

issue commentw3c/csswg-drafts

[css-variables] Substitution of invalid variables into other variables

So this is about https://bugzilla.mozilla.org/show_bug.cgi?id=1623396, right? Which landed in Firefox 76, which is most definitely not the most recent stable release (that was released mid-may, so we've been shipping this for more than two months).

As I said in https://github.com/w3c/csswg-drafts/issues/4075 I'm not particularly a fan of the current behavior (I slightly prefer the previous one). That being said, I see arguments both ways, and switching behaviors back and forth is really unfortunate, as @andruud said.

If the spec changes I'd be ok changing behavior in Gecko again, though given the discussion in #4075 and the fact that all browsers now agree on the behavior I think the value of the spec change needs to be huge.

Independent components can no longer be nested (especially if they're two instances of the same component) if they use the same variables and rely on fallback behavior of var references var(.., UNREACHABLE). (This is arguably the single most important reason the previous FF and Chrome behavior was very useful)

Can you clarify? Your example with code and i needs an extra variable indirection to produce red, but an author could pretty much use --color: initial to get the fallback behavior on the background image. Or they could use the fallback for color like: --color: var(--foo, lime), right?

cc @tabatkins

James0x57

comment created time in 5 days

issue commentrust-lang/rust-bindgen

the name <whatever> is defined multiple times + cannot find `T` in this scope

You probably need to blacklist those. This is likely templates making bindgen sad.

LoganDark

comment created time in 6 days

issue commentrust-lang/rust-bindgen

[c++] Invalid free when destroying a class with an std::string member

Apparently we only have a note about the different move semantics:

Automatically calling copy and/or move constructors or destructors. Supporting this isn't possible with Rust's move semantics.

It's a bit of a stretch expecting people would figure out that classes relying on these (like std::string, to keep track of the interior pointer) won't work properly when moved, and definitely unexpected that the auto-generated ::new() causes a move.

So we should definitely expand the C++ docs to explain this.

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

[c++] Consider implementing Drop for types with destructors

You said that #1841 is the same as this issue and renamed this issue. But adding the default destructor/default constructor and calling the deconstructor using the drop trait are two seperate things. You can do the first thing without doing the second.

Well, kinda, right? If we auto-implement drop, then default constructors between Rust and C++ behave the same don't they?

I'm not sure under which circumstances a C++ compiler emits symbols for a default constructor, if it does at all. If you have info on that we can try to elaborate a solution for it.

Volker-Weissmann

comment created time in 7 days

issue commentw3c/csswg-drafts

[cssom-view] Definition of clientLeft and clientTop doesn't make sense for the document scrolling element.

Ah, so @bzbarsky agreed with me like 4 years ago ;)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29603

emilio

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should we mention aspect-ratio in margin collapsing?

@bfgeek do we actually need to make inline-size: 0 work?

It'd be nice not to add more special cases to margin collapsing, I'd prefer to consider any finite ratio as not empty for margin collapsing purposes, but...

BorisChiou

comment created time in 7 days

issue commentrust-lang/rust-bindgen

std::vector<int>::iterator creates trouble

I appreciate a lot all the reduced test-cases @Volker-Weissmann, thank you!

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

std::vector<int>::iterator creates trouble

Yeah, these are not necessarily unfixable though :)

I think we should not generate a bunch of these constants #1838. Same goes for the typedefs.

I haven't been catching up lately with all the rust improvements, but chances are that a few of those can be "properly" supported with stuff inside generic impl blocks like:

impl<T> Generic<T> {
   pub type Bar = Foo<T>;
}

Or such.

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Bindgen generates incorrect constants for anonymous enums with fixed underlying types

(Renaming the issue title to clarify that I don't think the types are technically incorrect, unless I'm missing something)

csmulhern

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Bindgen generates incorrect constants for anonymous enums with fixed underlying types

So... right, this is somewhat unfortunate because anonymous enums are somewhat hard to handle, specially given all the different tweaks that you can apply in bindgen to get different APIs / generated code for enums.

We need the underlying integer type to get the right layout for some of those. We lose that information in the canonical_type call right below the code you linked... But I think we could preserve that type a bit further without too much trouble I think.

So for example something like this:

diff --git a/src/codegen/mod.rs b/src/codegen/mod.rs
index c68eb6da..d0b96221 100644
--- a/src/codegen/mod.rs
+++ b/src/codegen/mod.rs
@@ -2859,9 +2859,12 @@ impl CodeGenerator for Enum {
             });
         }
 
-        let repr = {
-            let repr_name = ctx.rust_ident_raw(repr_name);
-            quote! { #repr_name }
+        let repr = match self.repr() {
+            Some(ty) => ty.to_rust_ty_or_opaque(ctx, &()),
+            None => {
+                let repr_name = ctx.rust_ident_raw(repr_name);
+                quote! { #repr_name }
+            },
         };
 
         let mut builder = EnumBuilder::new(

Gets us the first expected output in your last comment. Then, for the case of an unnamed enum and the Consts enum style, we could go further and use that repr as the type of the different constants directly, which would get the best output I think. Then we could even omit the _bindgen_ty_1 definition altogether in that case, if wanted.

I'd be fancy with any of those options getting submitted as a patch along with some tests :)

csmulhern

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Bindgen generates incorrect constants for anonymous enums with fixed underlying types

Sorry for the lag in getting to this, looking now :)

csmulhern

comment created time in 7 days

issue commentrust-lang/rust-bindgen

IncompleteArrayField Ergonomics

per the above I don't think this is particularly actionable, but let me know / reopen if I'm wrong :)

ssbanerje

comment created time in 7 days

issue closedrust-lang/rust-bindgen

IncompleteArrayField Ergonomics

This is not a bug report, its a feature request.

It seems like the __IncompleteArrayField type could be replaced to make it much more ergonomic.

Input C/C++ Header

struct vfio_irq_set {
	__u32	argsz;
	__u32	flags;
#define VFIO_IRQ_SET_DATA_NONE		(1 << 0) /* Data not present */
#define VFIO_IRQ_SET_DATA_BOOL		(1 << 1) /* Data is bool (u8) */
#define VFIO_IRQ_SET_DATA_EVENTFD	(1 << 2) /* Data is eventfd (s32) */
#define VFIO_IRQ_SET_ACTION_MASK	(1 << 3) /* Mask interrupt */
#define VFIO_IRQ_SET_ACTION_UNMASK	(1 << 4) /* Unmask interrupt */
#define VFIO_IRQ_SET_ACTION_TRIGGER	(1 << 5) /* Trigger interrupt */
	__u32	index;
	__u32	start;
	__u32	count;
	__u8	data[];
};

Bindgen Invocation

let bindings = bindgen::Builder::default()
    .header(vfio_wrapper)
    .derive_debug(true)
    .impl_debug(true)
    .rustified_enum(r".*")
    .whitelist_type(r"^vfio_.*")
    .whitelist_var(r"^VFIO_.*")
    .whitelist_var(r"^PCI_.*")
    .generate()
    .expect("Unable to generate bindings");

Actual Results

#[repr(C)]
#[derive(Debug)]
pub struct vfio_irq_set {
  pub argsz: __u32,
  pub flags: __u32,
  pub index: __u32,
  pub start: __u32,
  pub count: __u32,
  pub data: __IncompleteArrayField<__u8>,
}

Expected Results

Based on the documentation available in the nomicon (https://doc.rust-lang.org/nomicon/exotic-sizes.html#dynamically-sized-types-dsts), I would expect the generated code to look like this:

#[repr(C)]
#[derive(Debug)]
pub struct vfio_irq_set<T: ?Sized> {
    pub argsz: u32,
    pub flags: u32,
    pub index: u32,
    pub start: u32,
    pub count: u32,
    pub data: T,
}

This code is much more ergonomic to use than the one generated by bindgen.

For example, to create a new instance of this type, we can simply use safe rust

let vis = vfio_irq_set<[u8;16]> {
  argsz:  (std::mem::size_of::<vfio_irq_set>() + std::mem::size_of::<u8>() * 16) as u32,
  ...
  data: [0xea; 16],
}

Compared to the unsafe pointer wrangling required to deal with the code generated by bindgen

let size = std::mem::size_of::<vfio_irq_set>() + std::mem::size_of::<u8>() * 16;
let layout = Layout::from_size_align(size, std::mem::align_of::<Self>()).unwrap();
unsafe {
      let mut vis = alloc(layout) as *mut vfio_irq_set;
      (*vis).0.argsz = size as u32;
      let data = (*vis).data.as_mut_slice(16)
      ...
}

Then there is of course the deallocation as well.

closed time in 7 days

ssbanerje

issue commentrust-lang/rust-bindgen

Use Bindgen names in Object-C pointer input and return types.

Returning more strongly typed things sounds useful to me, for what is worth, if we can get that information.

simlay

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Segfault when running into C++ union with variadic templates

Huh, fun. Thanks for the reduced test-case, that's awesome! And sorry you hit this bug :(

We're overflowing the stack here:

#48539 0x0000555555921c58 in bindgen::ir::comp::CompInfo::layout (self=0x555556048570, ctx=0x7ffffffea598) at src/ir/comp.rs:1115
#48540 0x00005555558b4382 in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:256
#48541 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48542 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048538, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48543 0x00005555558b45af in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:267
#48544 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48545 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048a60, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48546 0x0000555555920112 in bindgen::ir::comp::Field::layout (self=0x555555fdcba0, ctx=0x7ffffffea598) at src/ir/comp.rs:207
#48547 0x0000555555921c58 in bindgen::ir::comp::CompInfo::layout (self=0x555556048570, ctx=0x7ffffffea598) at src/ir/comp.rs:1115
#48548 0x00005555558b4382 in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:256
#48549 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48550 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048538, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48551 0x00005555558b45af in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:267
#48552 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48553 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048a60, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48554 0x0000555555920112 in bindgen::ir::comp::Field::layout (self=0x555555fdcba0, ctx=0x7ffffffea598) at src/ir/comp.rs:207
#48555 0x0000555555921c58 in bindgen::ir::comp::CompInfo::layout (self=0x555556048570, ctx=0x7ffffffea598) at src/ir/comp.rs:1115
#48556 0x00005555558b4382 in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:256
#48557 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48558 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048538, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48559 0x00005555558b45af in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:267
#48560 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48561 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048a60, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48562 0x0000555555920112 in bindgen::ir::comp::Field::layout (self=0x555555fdcba0, ctx=0x7ffffffea598) at src/ir/comp.rs:207
#48563 0x0000555555921c58 in bindgen::ir::comp::CompInfo::layout (self=0x555556048570, ctx=0x7ffffffea598) at src/ir/comp.rs:1115
#48564 0x00005555558b4382 in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:256
#48565 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48566 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048538, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48567 0x00005555558b45af in bindgen::ir::ty::Type::layout::{{closure}} () at src/ir/ty.rs:267
#48568 0x000055555588a64c in core::option::Option<T>::or_else (self=..., f=...) at /home/emilio/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:768
#48569 0x00005555559aae1f in bindgen::ir::ty::Type::layout (self=0x555556048a60, ctx=0x7ffffffea598) at src/ir/ty.rs:254
#48570 0x0000555555920112 in bindgen::ir::comp::Field::layout (self=0x555555fdcba0, ctx=0x7ffffffea598) at src/ir/comp.rs:207
#48571 0x0000555555921c58 in bindgen::ir::comp::CompInfo::layout (self=0x555556048570, ctx=0x7ffffffea598) at src/ir/comp.rs:1115

So we end up with a cyclic graph (which is not supposed to happen), and then trying to traverse it just gets us stuck :(

We should figure out what is going on here. I would expect this type to be rejected early because it has non-type template parameters (the variadic parameter list), but it clearly is not getting rejected properly.

talbenari1

comment created time in 7 days

issue closedrust-lang/rust-bindgen

Complex C++ template causes invalid Bindgen output

This is quite difficult to explain without an example, so here's a super-contrived header:

template <typename T, T init>
struct Foo {
  const static T value = init;
};

template <typename T, T init>
const T Foo<T, init>::value;

Bindgen has no problems generating the bindings for this header file, but the output looks like this:

/* automatically generated by rust-bindgen */

#[allow(non_snake_case, non_camel_case_types, non_upper_case_globals)]
pub mod root {
    #[allow(unused_imports)]
    use self::super::root;
    extern "C" {
        pub static value: T;
    }
}

The error when trying to compile the generated Rust bindings is error[E0412]: cannot find type `T` in this scope, which should be fairly clear from the output above.

Note: I found this after lots of debugging and trial-and-error; ultimately the problem was located in the <type_traits> system header file on my machine. You might be able to reproduce this, like I did, simply via #include <type_traits>.

closed time in 7 days

talbenari1

issue commentrust-lang/rust-bindgen

Template trouble

Yeah, this is template sadness. We should probably not generate initializers for templated statics.

Volker-Weissmann

comment created time in 7 days

issue closedrust-lang/rust-bindgen

Feature request: Drop trait deconstructor

Consider the following C++ header:

class MyClass {
public:
	MyClass();
	~MyClass();
};

If you want to construct and destruct a MyClass object, you would have to write

let mut val = MyClass::new();
val.destruct();

It would be nice if rust bindgen would add this:

impl Drop for MyClass {
	fn drop(&mut self) {
		unsafe {
			self.destruct();
		}
	}
}

Which would allow you to just write

let val = MyClass::new();

which would call the constructor and destructor.

closed time in 7 days

Volker-Weissmann

issue commentrust-lang/rust-bindgen

Feature request: Drop trait deconstructor

Yeah, this is basically https://github.com/rust-lang/rust-bindgen/issues/1840. See there why this is not done by default. We could these days I think, with that breaking change of making stuff a ManuallyDrop when we implement drop.

Let's dupe this against that issue as you filed it earlier.

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

[c++] Invalid free when destroying a class with an std::string member

I think we have documentations about interior pointers and such (that's basically why ::new() is unsafe), but if we don't we should get some.

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Invalid free

I think this is because of a combination of two things:

  • Your std::string has internal pointer optimizations (so the empty string points to a buffer inside the string object).
  • Rust is generating a memmove in MySpace_MyString::new (so the object moves in memory but that pointer isn't fixed up).

Does it work if you inline the MySpace_MyString::new? So if you do:

let mut val = MaybeUninit::<MySpace_MyString>::uninit();
MySpace_MyString_MyString(val.as_mut_ptr());
MySpace_MyString_MyString_destructor(val.as_mut_ptr());

?

That'd confirm that theory.

Volker-Weissmann

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Bindgen doesn't support environment variables like `CC`

Can you clarify where does that error come from? Bindgen doesn't link anything for you so I suspect the issue is somewhere else.

LoganDark

comment created time in 7 days

issue commentrust-lang/rust-bindgen

bindgen takes like a minute per C++ struct & produces gigabytes of log output with debug logging enabled

Well, it kinda was but worth double-checking... We could probably turn a bunch of the debug logs into trace logs or such, and for super noisy stuff we could definitely trim it down...

I've mostly used debug logging for reduced test-cases for which all that extra info is helpful.

LoganDark

comment created time in 7 days

issue commentrust-lang/rust-bindgen

libloading support

Sorry for the lag replying here, but if people are fine with all functions from a set of bindings ending up in the same LibLoading thing then the proposal above seems sensible. If interested folks could give it a spin and see if it works for them it'd be awesome.

Thanks!

Wenzel

comment created time in 7 days

pull request commenteqrion/cbindgen

Add Github Actions

Hmm, not particularly excited about having two CI systems. We should have just one. I don't have a problem to switch to github actions if it's better, but I probably need admin on the repo or such which I don't have :)

Luni-4

comment created time in 7 days

pull request commenteqrion/cbindgen

Add an attribute to tell cbindgen how to present pointers

That's not great because we'd end up having to maintain two different syntaxes, which is painful for such a tiny feature with no impact on correctness.

Luni-4

comment created time in 7 days

issue commentrust-lang/rust-bindgen

Missing default constructor and default deconstructor

Yes, you need to implement Drop yourself, because it can cause unsoundness otherwise.

For example, if bindgen would implement Drop by default, dropping Outer would end up calling ~Inner twice, once from Rust, once from C++, which is bad.

We could fix that using ManuallyDrop for members of structs that have destructors nowadays, I think.

Volker-Weissmann

comment created time in 7 days

more