Change:
return; } <del> let merged_prefix_len = self.curr_original_span.lo() - curr.span.lo(); let after_macro_bang = merged_prefix_len + BytePos(visible_macro.as_str().len() as u32 + 1); if self.curr().span.lo() + after_macro_bang > self.curr().span.hi() { </del> <ins> // The split point is relative to `curr_original_span`, // because `curr.span` may have been merged with preceding spans. let split_point_after_macro_bang = self.curr_original_span.lo() + BytePos(visible_macro.as_str().len() as u32) + BytePos(1); // add 1 for the `!` debug_assert!(split_point_after_macro_bang <= curr.span.hi()); if split_point_after_macro_bang > curr.span.hi() { </ins> // Something is wrong with the macro name span; <del> // return now to avoid emitting malformed mappings. // FIXME(#117788): Track down why this happens. </del> <ins> // return now to avoid emitting malformed mappings (e.g. #117788). </ins> return; } let mut macro_name_cov = curr.clone(); <del> self.curr_mut().span = curr.span.with_lo(curr.span.lo() + after_macro_bang); macro_name_cov.span = macro_name_cov.span.with_hi(macro_name_cov.span.lo() + after_macro_bang); </del> <ins> macro_name_cov.span = macro_name_cov.span.with_hi(split_point_after_macro_bang); self.curr_mut().span = curr.span.with_lo(split_point_after_macro_bang); </ins> debug!( "  and curr starts a new macro expansion, so add a new span just for  the macro `{visible_macro}!`, new span={macro_name_cov:?}",

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried to run on this code: I expected the tool to work normally, but instead, this happened: Please note this is the most minimal reproducible example I've been able to find. Removing either the attribute or the call does not reproduce the error, but the has not effect. I've tried to remove the dependency but putting the required code in the same file or in a different crate (in the same workspace) does not reproduce the error. It most recently worked on: 1.73.0 <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
cc
I was able to reproduce this on beta+nightly on my machine (macOS aarch64), so I should be able to dig into the mappings and see what LLVM is complaining about. (Thanks for the detailed report!)
This seems to be where the error is coming from:
When the error occurs in the above code, we have startLoc = (159, 59) and endLoc = (1, 4), causing the check to fail. That seems to correspond to this code:
If I print out the raw values being read by , I see: That NumLines value is 0xFFFFFF62, which is clearly bogus. Probably the result of integer overflow somewhere.
Actually I've traced the bogus (1, 4) coordinates to the actual span processed by . It looks like is producing a bogus span that extends into an adjacent file, completely trashing the span coordinates. At this point I'm guessing the culprit is .
Hmm, but I can reproduce this on , which predates the merge of , so I should look at changes earlier than that.
Manually bisected this down to (good) to (bad).
After some more manual bisection, I'm pretty sure this started failing after .

That seems consistent with it being a latent coverage bug that has now been made more common by compiler-wide changes to spans.
Even in prior revisions I can observe the spans created by sometimes being bogus; they're just bogus in a way that tends not to result in malformed mappings and failures.
(In this situation,  should work fine to avoid bisecting manually)
The fix for this has been cherry-picked into the upcoming stable release of 1.74, and has also been merged on nightly (1.76). It will probably still be broken in the initial version of the upcoming beta release (1.75); ideally the fix will also be be accepted on the beta branch at some point in the next 5 weeks.