From: HeeSu Kim <mlksvender@gmail.com>
To: miguel.ojeda.sandonis@gmail.com
Cc: a.hindborg@kernel.org, aliceryhl@google.com,
bjorn3_gh@protonmail.com, boqun@google.com, charmitro@posteo.net,
dakr@kernel.org, gary@garyguo.net, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org, lossin@kernel.org,
mlksvender@gmail.com, nathan@kernel.org, nsc@kernel.org,
ojeda@kernel.org, rust-for-linux@vger.kernel.org,
tmgross@umich.edu
Subject: Re: [PATCH v2] rust: Makefile: bound rustdoc workaround to affected versions
Date: Tue, 3 Feb 2026 10:46:13 +0900 [thread overview]
Message-ID: <20260203014613.2708234-1-mlksvender@gmail.com> (raw)
In-Reply-To: <CANiq72n39eU9WE=Yh0_yJzmqMxo=QAaU2pN0UqP9jZ7bT7rhgA@mail.gmail.com>
On Mon, 3 Feb 2026, Miguel Ojeda wrote:
> On Mon, Feb 3, 2025 at 1:09 AM HeeSu Kim <mlksvender@gmail.com> wrote:
> >
> > The `-Cunsafe-allow-abi-mismatch=fixed-x18` workaround was added to
> > handle a rustdoc bug (rust-lang/rust#144521) where target modifiers
> > were not properly saved.
> >
> > This bug was fixed in Rust 1.90.0 (rust-lang/rust#144523). Restrict
>
> We tend to use `Link:` tags for these. Typically we write a line like:
>
> Link: https://github.com/rust-lang/rust/issues/144521
>
> If you want to reference it inline, you can also just put the full URL.
>
> > Suggested-by: Gary Guo <gary@garyguo.net>
>
> Please add a `Link:` tag after this one pointing to his message.
>
> > Fixes: abbf9a449441 ("rust: workaround `rustdoc` target modifiers bug")
>
> I am not so sure this is a fix -- after all, when you use `1.88` or
> `1.89`, nothing would change. So it is more of a feature? i.e. the
> ability to use `1.90`.
>
> But I guess it could also be understood as "we should have applied
> this only for affected versions to begin with", but then it would be
> from a "code documentation" perspective, which is fine, but it is not
> something that e.g. we would need to backport. So I am leaning towards
> not having a `Fixes:` here.
>
> And this has another issue (though a different patch): the `sanitizer`
> modifier.
>
> By the way, I wonder if we would want at least a `rustc-max-version`
> (or an `-until` variant, or whatever) so that we can easily express
> that range in a single call, and document the bounds together (I could
> imagine that we could end up with a few of these over time, and then
> they start to shift versions, they get spread across lines, etc.).
>
> Perhaps the Kbuild maintainers can comment on whether that would be a
> good idea or whether they already have something.
>
> Cheers,
> Miguel
Thanks for the detailed feedback.
For v3, I will:
- Use full Link: tags for GitHub references instead of shorthand
- Add Link: tag after Suggested-by pointing to Gary's lore message
- Remove the Fixes: tag
- Add Cc: stable@vger.kernel.org # Useful in 6.18.y and later.
Regarding rustc-max-version, it would be useful for reading the code.
I'll wait for Kbuild maintainers' reply.
Best regards,
HeeSu Kim
next prev parent reply other threads:[~2026-02-02 16:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 22:21 [PATCH] rust: Makefile: apply fixed-x18 workaround only on arm64 HeeSu Kim
2026-02-02 13:59 ` Charalampos Mitrodimas
2026-02-02 23:17 ` HeeSu Kim
2026-02-02 14:20 ` Miguel Ojeda
2026-02-02 14:24 ` Gary Guo
2026-02-02 23:45 ` HeeSu Kim
2026-02-03 0:21 ` [PATCH v2] rust: Makefile: bound rustdoc workaround to affected versions HeeSu Kim
2026-02-02 16:00 ` Miguel Ojeda
2026-02-03 0:56 ` Nathan Chancellor
2026-02-03 23:48 ` [PATCH v4] " HeeSu Kim
2026-02-03 22:12 ` Nathan Chancellor
2026-02-05 13:15 ` HeeSu Kim
2026-02-05 13:18 ` [PATCH v5 1/2] kbuild: add rustc-max-version macro HeeSu Kim
2026-02-05 13:18 ` [PATCH v5 2/2] rust: Makefile: bound rustdoc workaround to affected versions HeeSu Kim
2026-03-12 14:12 ` Miguel Ojeda
2026-02-05 15:55 ` [PATCH v5 1/2] kbuild: add rustc-max-version macro Nicolas Schier
2026-03-10 22:45 ` Miguel Ojeda
2026-02-03 1:46 ` HeeSu Kim [this message]
2026-02-03 9:17 ` [PATCH v3] rust: Makefile: bound rustdoc workaround to affected versions HeeSu Kim
2026-02-03 14:56 ` [PATCH v2] " Gary Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260203014613.2708234-1-mlksvender@gmail.com \
--to=mlksvender@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@google.com \
--cc=charmitro@posteo.net \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox