These are two minor follow-ups to #1850.

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

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.

I did that tweak and merged. Thanks!

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

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

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.

These are two minor follow-ups to #1850.

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.

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!

nit: use the shorthand notation? repr, variants,

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.

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

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

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

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

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.

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

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.

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).

Great, thanks for checking!

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

This PR adds references section for dfn autolinks.

Fixes #555

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

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.

Yes, I agree that this is a cbindgen bug.

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.

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

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.

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

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.

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?

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

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!

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.

<!-- 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:

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:

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:

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

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

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 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.

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!

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.

Fixes #554

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

Fixes #554

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 :)

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...

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

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.

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.

unwrap_or_default()

same here.

nit: Stray newline.

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

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

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

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

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.

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.

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

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

@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...

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

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.

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

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 :)

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

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

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.

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

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.

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>.

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

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.

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.

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.

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.

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

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.

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!

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 :)

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.

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.