Re: [PATCH] rust: doctest: fix line numbers after crate-level attributes

[Younes]

On Wed, 28 Oct 2026 08:30:43 +0100, Miguel Ojeda wrote:
> On Tue, Oct 27, 2026 at 7:32 AM Younes Akhouayri via B4 Relay
> <devnull+git.younes.io@xxxxxxxxxx> wrote:

> This looks OK, and I think it fixes all the cases we have currently,
> but it doesn't cover every case one may write (like a multi-line
> attribute), i.e. I was wondering whether the complexity of this is
> worth it or not (especially if later on we try to support every case).
> But it may be that never happens, or happens way less often than even
> this case that we may not even care.

Right. I checked with rustdoc 1.98.1: a multi-line `#![...]` is still
off, and so is a blank line right after the attribute or an
`extern crate` line, since rustdoc moves those above `main` too. None
of these appear in the kernel crate's doctests today; all 12 current
cases are single-line attributes.

Covering them would mean relying on more of rustdoc's output layout,
e.g. the blank line it inserts after the moved attributes but not after
`extern crate`. That feels like more than this is worth, so I'd keep
the simple version and say in the comment that only single-line
attributes are handled, unless you'd rather drop it.

>
> By the way, why `saturating_sub` in particular? I guess because of
> underflow, but can that happen? And if it can (perhaps in a future
> compiler version), wouldn't we want to notice?

It can only underflow if rustdoc stops emitting its own
`#![allow(unused)]`, e.g. in a future version. A related case is a
crate setting `#![doc(test(attr(...)))]`: rustdoc then emits those
attributes instead, so the `- 1` can silently become wrong and
doctests without any attributes get shifted. Either way we'd want to
notice, so in v2 I'll check that the first line is `#![allow(unused)]`
and panic otherwise, instead of clamping. What do you think?

Thanks!

Younes