-
Notifications
You must be signed in to change notification settings - Fork 717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doctests fail with rust 1.26 #1313
Comments
I guess this should be an issue in the rust repo, unless it's a bindgen regression. |
The relevant C comment from #1478 is: I don't think it really makes sense to run doctests on comments that come from FFI headers, but I'm not aware of any way to skip them in a per-module basis. |
I just encountered the same problem when translating this function. It's pretty easy to see why rustdoc complains about broken tests around line 8109 of the generated code, although it doesn't look like there's an easy way for In my case an easy workaround is to blacklist the function and write its |
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
So @emilio I think a reasonable solution to this is to use the same detection code as a rustdoc to detect if any untagged (i.e. doesn't manually specify ```rust) codeblocks exist in the generated code, and if the code is not explicitly Rust code, tag it as Curious to know your thoughts on how to go about fixing this issue though! |
Right, I don't see a great solution here that doesn't involve parsing the doc comments, which is kinda nasty. I think ideally adding a rustdoc attribute to ignore this would be better, but see rust-lang/rust#38825 |
Generating comments in bindings can cause doc tests to fail, see rust-lang/rust-bindgen#1313
…dentally be generated from C comments See rust-lang/rust-bindgen#1313 Co-authored-by: StripedMonkey <[email protected]>
now that #2347 landed. This can be solved by implementing #[derive(Debug)]
struct Cb;
impl ParseCallbacks for Cb {
fn process_comment(&self, comment: &str) -> Option<String> {
Some(format!("````\n{}\n````", comment))
}
} or parsing it with a javadoc parser (not sure if such thing exists in Rust) |
@pvdrz I use bindgen v0.63.0:
The doctest still fails, seems |
you're using |
Thanks, it works but doctest still fail. Original comment format:
" |
I believe |
After double check, there are 2 types: C:
Rust:
Error:
|
The
Is a rust code snippet. adding the |
Thanks a lot, it makes all doctests ignored. BTW, for now, is there any plan to make doctests pass rather than ignored? |
Also, even |
Well there's not much you can do there other than using a javadoc parser and then turn that into valid markdown. You could try and come up with your own ad-hoc rules to try and fix your current comments by escaping certain characters like |
Whoops... Maybe this was a merge issue and the feature ended up in the wrong version |
It would be better to update the package to keep sync with the CHANGELOG. |
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
In some cases, C comments end up looking like indented code blocks. rustdoc thinks those are doctests and tries to run them. Bindgen is working on a workaround, but in the meantime, the easiest solution is just disabling doctests crate-wide. See rust-lang/rust-bindgen#1313
Input C/C++ Header
Bindgen Invocation
Actual Results
The bindings build correctly, but when I run
cargo test
I get the following error when rust 1.26 tries to build run doctests:The generated bindings are
Expected Results
I expect all doctests to pass. In particular, as I understood previous issues (e.g., #426) rust should even skip them in such a case. Is this a regression or an intended change in rust 1.26? It worked fine with rust 1.25.
The text was updated successfully, but these errors were encountered: