Skip to content
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

Fixes 'unresolved link to ...' when brackets are present in comments #1956

Closed
wants to merge 3 commits into from

Conversation

nwmqpa
Copy link

@nwmqpa nwmqpa commented Dec 23, 2020

Related to #1955

Copy link
Contributor

@emilio emilio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm not totally opposed to this, but if we really want to fix rustdoc's interactions with bindgen, that's a quite large task, see also #1313 or such...

I kinda feel that patching one issue at a time would be mostly just working around it.

I think a better option could be to just wrap all doc comments bindgen emits into triple-backticks, effectively, and then escape those from the comment content?

I think that'd fix what you're hitting and pretty much all those related issues, plus it would more generally preserve the C comment style, which is not expected to be parsed as markdown (rustdoc messes up all sorts of ascii art or what not).

I suspect it should also not be much implementation work, wdyt?

///
/// Avoid processing expensive computations if no brackets are found
fn preprocess_plain_brackets(line: &str) -> String {
if line.contains("[") && line.contains("]") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not do two scans of the string?

/// Avoid processing expensive computations if no brackets are found
fn preprocess_plain_brackets(line: &str) -> String {
if line.contains("[") && line.contains("]") {
line.chars()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kinda feel this would be more readable as a regular for loop, but maybe it's just me so if you feel strongly against that no big deal :)

/// Preprocesses comments containing brackets to prevent `unresolved link to ...`
///
/// Avoid processing expensive computations if no brackets are found
fn preprocess_plain_brackets(line: &str) -> String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's return a Cow<str> instead and avoid cloning the string if there are no brackets.

@nwmqpa
Copy link
Author

nwmqpa commented Dec 28, 2020

So, to sum up, what you said, you think that making the whole comment block become Markdown, by prepending and appending it with triple-backticks, which would be easier to escape actual backticks in the sequence (String::replace maybe?). Did I get it right?

Besides that, my fix was supposed to be the least intrusive possible, in order not to break the tests in place, what you meant is that we should re-write tests to implement this fix.

@emilio
Copy link
Contributor

emilio commented Dec 29, 2020

So, to sum up, what you said, you think that making the whole comment block become Markdown, by prepending and appending it with triple-backticks, which would be easier to escape actual backticks in the sequence (String::replace maybe?). Did I get it right?

Yeah, I think that's right.

Besides that, my fix was supposed to be the least intrusive possible, in order not to break the tests in place, what you meant is that we should re-write tests to implement this fix.

Yeah, tests should be automatically rewritten (the ones that test generated output, that is) by using BINDGEN_OVERWRITE_EXPECTED=1 cargo test. About the unit tests specifically about comments, yeah, I'm not too concerned about those. They're somewhat useless nowadays that we use quote to generate the comments (which turns them into #[doc] attributes anyways).

@emilio
Copy link
Contributor

emilio commented Jan 29, 2021

Sorry for the lag. This looks generally good, it seems CI is red because probably expectations for older libclang versions need adjusting. Let me know if you don't have the cycles to finish it up and I can try to pick this up.

Thanks for the patch!

@nwmqpa
Copy link
Author

nwmqpa commented Jan 29, 2021

What would be needed in order to adjust the libclang so that the CI goes green ?

@emilio
Copy link
Contributor

emilio commented Feb 7, 2021

Sorry, I missed that comment. The CI run in https://github.com/rust-lang/rust-bindgen/runs/1624844280 prints the diffs of the tests that failed, so far it seems like a matter of changing the test expectation in this case.

@bors-servo
Copy link

☔ The latest upstream changes (presumably 0e25962) made this pull request unmergeable. Please resolve the merge conflicts.

@pvdrz
Copy link
Contributor

pvdrz commented Apr 13, 2023

Closing this at the same can be done by providing an implementation of ParseCallbacks::process_comment that handles brackets accordingly.

@pvdrz pvdrz closed this Apr 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants