Skip to content

Conversation

@MarijnS95
Copy link
Contributor

The function in question doesn't store the dyn Write trait object anywhere, allowing us to pass a plain &mut dyn Write (which is also implemented for &mut Box<dyn Write> allowing the existing CLI parser to operate normally).

This in turn no longer requires users of bindgen to wrap their &mut File or &mut Vec<u8> in a moved Box just to be able to give temporary mutable access to the write() function.

The function in question doesn't store the `dyn Write` trait object
anywhere, allowing us to pass a plain `&mut dyn Write` (which is also
implemented for `&mut Box<dyn Write>` allowing the existing CLI parser
to operate normally).

This in turn no longer requires users of `bindgen` to wrap their
`&mut File` or `&mut Vec<u8>` in a moved `Box` just to be able to give
temporary mutable access to the `write() function`.
@MarijnS95
Copy link
Contributor Author

Note that I am using this on a project where fn new_item_found() is implemented on ParseCallbacks, where I generate a special impl (based on some name mangling) for certain structs; and later append that to a &mut File that I specifically opened up-front for both bindgen and my custom thing to write to, rather than reopening it again after fn write_to_file().

If there was an option for ParseCallbacks to emit custom code after the visited element (so that my impls will also live right after the respective struct declarations) this workaround wouldn't have been needed - but it leads to some nicer API nevertheless?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant