Most of this function's body is copied from to. We can't just do self.to(end.shrink_to_lo()), because to also does some magic where it uses min/max so it can handle overlapping spans (I think, the logic is a bit wonky).

Add a comment saying so or refactor the common logic to a new method.

The overflow happens here, because the lines of cur_hi and cur_lo are never checked against each other, so if lo starts in an earlier line but with a higher column, we get an overflow.

Now, we can properly fix this, and probably should, but the span that we have here is nonsensical to begin with. It goes from bar( inside the macro to the start of true at the call site of the macro.

Ah! Yes, that's why we are getting these malformed spans. Yeah, macros screw everything up. Maybe we should have an assert (not an assert, a check) for well formed spans before we even try to emit or add a suggestion to the DiagnosticBuilder? That would make it so we never show suggestions like this one, while also not breaking the emitter logic. We should probably log that though.

I hate Spans sourced from macros 🥺

We could add an actual assert! here. At least if anyone hits it we'll get a traceback.

By the time we get here, the span doesn't look malformed anymore. The fault is either at the until method or at the caller to it. Maybe we should return an option instead of a span? Or a dummy span in case there are macros involved?

We could tell that lo > hi, right? And in the Span wrangling methods we should check that both spans belong to the same Ctxt, and if not die in nightly and return only one of the original spans in beta/stable. Changing this to Option would be a royal pain in the neck.

yea, debug asserting this would be best. We'll have to fix a bunch of diagnostics code that currently relies on it.

I'm bumping into this overflow (again) in Clippy. Still not sure why it hasn't shown up in CI. But I narrowed it down to a suggestion that replaces an else block, so the block starts at a higher column than where it ends.

@camsteffen yeah, didn't ping you on this PR when oli noticed this, but it is likely the same issue and this PR should help (but likely give... incorrect suggestions).

I don't think the problem is only with invalid spans. Here is a minimal reproduction (triggers anonymous_parameters).

trait X {
    fn test(x: u32, (
    )) {}
}