linux-kernel - Re: [PATCH 1/1] Use new `--output-format=doctest` rustdoc command line flag to improve doctest handling.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72=UrE5fv1Ymt-2NRzzKo2xk=tXLwvLaC4fo+vhJC0edNw@mail.gmail.com>
Date: Fri, 28 Feb 2025 17:48:25 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Guillaume Gomez <guillaume1.gomez@...il.com>
Cc: ojeda@...nel.org, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] Use new `--output-format=doctest` rustdoc command
 line flag to improve doctest handling.

On Fri, Feb 28, 2025 at 5:32 PM Guillaume Gomez
<guillaume1.gomez@...il.com> wrote:
>
> I'll definitely need some help here. I'm not sure current stable already
> has this change so until then, we'll need a beta/nightly version to run
> these tests.

Yeah, we will need to wait until the "final" version of the flag is in
a stable version (the flag would not need to be "stable" itself, nor
the compiler released, but yeah, we need to know the version).

> I opened https://github.com/rust-lang/rust/pull/137807 to resolve
> this problem.

Thanks!

That would still force us to have all the "hardcoded knowledge" about
the `rustdoc` output (apart from the JSON schema), right?

i.e. my idea was to try to see if we could avoid matching on "strings"
as much as possible, and trying to have enough metadata (properly
encoded in the JSON somehow), so that we need to avoid searching for
e.g. `main()` etc.; and instead generate everything else needed on our
side, customized for the kernel case.

> I don't think `expect` would work in any of the cases in this file. What I suggest
> is to add methods on `JsonValue` in a future patch which would allow to reduce
> code in this file (and call `expect` too).

Yeah, sorry, when I saw the `Some(...) ... else panic!` I replied too
quickly -- in this case, I don't think it matters to have a custom
error for the "wrong JSON type" case as we discussed offline since
nobody should be seeing the error to begin with, so it is fine.

Cheers,
Miguel