This line A calls Fragments::span(), which calls source_span_for_markdown_range, which is a fairly expensive function. That first case calls it just to check if we're on a line that terminates in \, and it's called about 700 times while analyzing tokio taking up about 10% of the Clippy runtime in that crate (which is unacceptable!).

Oh I didn't see the failling CI :/ GitHub seems to be funky with the CI interface in this PR.

This line A calls Fragments::span(), which calls source_span_for_markdown_range, which is a fairly expensive function. That first case calls it just to check if we're on a line that terminates in \, and it's called about 700 times while analyzing tokio taking up about 10% of the Clippy runtime in that crate (which is unacceptable!).

I see, but I suppose you don't have to go through that machinery to get the snippet and perform the check?

-                if let Some(span) = fragments.span(cx, range.clone())
-                    && !span.from_expansion()
-                    && let Some(snippet) = snippet_opt(cx, span)
-                    && !snippet.trim().starts_with('\\')
-                    && event == HardBreak {
-                    collected_breaks.push(span);
-                }
+                if event == HardBreak
+                    && !doc[range.clone()].trim().starts_with('\\')
+                    && let Some(span) = fragments.span(cx, range.clone())
+                    && !span.from_expansion() {
+                    collected_breaks.push(span);
+                }

(Edit: Also do the HardBreak check first to avoid string slicing, since softs are much more common)

CI now failing from missing derive(serde)

Honestly, I'm not sure how to proceed 😅 This PR is then a little bit redundant in our specific case. If the project would still appreciate it, I can do the necessary fixes for CI (which is proving tricky, I'll manually check .github/workflows).

If you think that it does not add any value, I have no problems closing it and using the patch you provided (with the appropriate authoring information for the commit)

I'm not sure either. Clearly there is a use for distinguishing the kinds of hard break, but it can be recovered fairly easily with offsets. The downside to this change is it makes it more cumbersome to match on Event, or to generate synthetic ones, like in the README example.

From a princpled perspective, if we add this, then in some sense we're also welcoming other AST enrichments like:

• ATX vs setext heading (# heading vs heading\n===)
• Bullet list marker (-, + or *)
• Ordered list delimiter (1. or 1))
• Emphasis marker (_ or *)

Also related to the discussion in #892

Opinions? @Martin1887 @notriddle

Either way, you're welcome to incorporate my patch in Clippy :)

I totally agree with your conclusions, we have to think about maintaining the current code or exposing more details, with a more cumbersome interface and breaking changes.

Thanks!

In that case, I'll close this PR. In case that in a distant future this feature is more needed in the project feel free to implement it without attribution hassle (it's a 20 line change)

Thanks for the feedback and the reviews, and have a good week!