Openembedded Core Discussions
 help / color / mirror / Atom feed
From: sunilkumar.dora@windriver.com
To: openembedded-core@lists.openembedded.org
Cc: richard.purdie@linuxfoundation.org,
	sundeep.kokkonda@windriver.com, sunilkumar.dora@windriver.com,
	Randy.Macleod@windriver.com, alejandro@enedino.org
Subject: [PATCH 4/5] rust: backport deterministic DocLinkResMap serialisation
Date: Tue, 15 Sep 2026 19:48:33 +0530	[thread overview]
Message-ID: <20260915141834.1212812-5-sunilkumar.dora@windriver.com> (raw)
In-Reply-To: <20260915141834.1212812-1-sunilkumar.dora@windriver.com>

From: Sunil Dora <sunilkumar.dora@windriver.com>

Backport of rust-lang/rust commit f9d9939 by jprochazk and mejrs.
DocLinkResMap was an UnordMap, so its iteration order varied with the
build host and that order reached the encoded rmeta. An FxIndexMap keeps
it stable. The commit is in rust 1.99, so this only carries it until the
next rust upgrade.

[YOCTO #16376]

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
---
 ...oc-link-metadata-order-deterministic.patch | 40 +++++++++++++++++++
 meta/recipes-devtools/rust/rust-source.inc    |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 meta/recipes-devtools/rust/files/0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch

diff --git a/meta/recipes-devtools/rust/files/0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch b/meta/recipes-devtools/rust/files/0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch
new file mode 100644
index 0000000000..8cd64f21bb
--- /dev/null
+++ b/meta/recipes-devtools/rust/files/0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch
@@ -0,0 +1,40 @@
+From 6630363e7bc9bc0926300e242aa538b8d92cdb95 Mon Sep 17 00:00:00 2001
+From: jprochazk <pjanv42@gmail.com>
+Date: Tue, 15 Sep 2026 17:05:36 +0530
+Subject: [PATCH] make DocLinkResMap an FxIndexMap
+
+DocLinkResMap was an UnordMap, so its iteration order varied with the build
+host and that order ended up in the encoded rmeta. An FxIndexMap keeps the
+serialisation stable. Only the code change is carried here, not the
+upstream run-make test.
+
+Upstream-Status: Backport [https://github.com/rust-lang/rust/commit/f9d9939467a5185a72f0ee8da778a0b71fc966ae]
+
+Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
+---
+ compiler/rustc_hir/src/def.rs | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/compiler/rustc_hir/src/def.rs b/compiler/rustc_hir/src/def.rs
+index d0300d6..e903c0c 100644
+--- a/compiler/rustc_hir/src/def.rs
++++ b/compiler/rustc_hir/src/def.rs
+@@ -4,7 +4,7 @@ use std::fmt::Debug;
+ 
+ use rustc_ast as ast;
+ use rustc_ast::NodeId;
+-use rustc_data_structures::unord::UnordMap;
++use rustc_data_structures::fx::FxIndexMap;
+ use rustc_error_messages::{DiagArgValue, IntoDiagArg};
+ use rustc_macros::{Decodable, Encodable, StableHash};
+ use rustc_span::Symbol;
+@@ -969,4 +969,6 @@ pub enum LifetimeRes {
+     ElidedAnchor { start: NodeId, end: NodeId },
+ }
+ 
+-pub type DocLinkResMap = UnordMap<(Symbol, Namespace), Option<Res<NodeId>>>;
++// FxIndexMap is necessary because its data ends up in .rmeta files, so its
++// iteration order must be consistent. See #159677 for context.
++pub type DocLinkResMap = FxIndexMap<(Symbol, Namespace), Option<Res<NodeId>>>;
+-- 
+2.43.0
diff --git a/meta/recipes-devtools/rust/rust-source.inc b/meta/recipes-devtools/rust/rust-source.inc
index a294201c6e..a50a3fd001 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -10,6 +10,7 @@ SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
             file://0004-Backport-commits-from-rust-Fix-selftest-llvm23.patch;patchdir=${RUSTSRC} \
             file://0005-rustc_codegen_llvm-Do-not-pass-amx-tf32-to-LLVM-23.patch;patchdir=${RUSTSRC} \
             file://0007-cargo-omit-host-triple-from-unit-metadata-hash.patch;patchdir=${RUSTSRC} \
+            file://0008-rustc-hir-make-doc-link-metadata-order-deterministic.patch;patchdir=${RUSTSRC} \
 "
 SRC_URI[rust.sha256sum] = "be1816e7f6c40abb90245ad6e024bed2a7e88d7dda4561e4d5470207df616b9f"
 
-- 
2.43.0



  parent reply	other threads:[~2026-09-15 14:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 14:18 [PATCH 0/5] rust: reproducibility fixes for arm build hosts sunilkumar.dora
2026-09-15 14:18 ` [PATCH 1/5] rust: drop the cc object-name reproducibility patch sunilkumar.dora
2026-09-15 14:18 ` [PATCH 2/5] rust: hash cc object names relative to their source roots sunilkumar.dora
2026-09-15 14:18 ` [PATCH 3/5] rust: keep the build host triple out of cargo unit metadata sunilkumar.dora
2026-09-15 14:18 ` sunilkumar.dora [this message]
2026-09-15 14:18 ` [PATCH 5/5] rust: sort hygiene data before it is encoded sunilkumar.dora
2026-09-15 15:53 ` [OE-core] [PATCH 0/5] rust: reproducibility fixes for arm build hosts Alejandro Hernandez
2026-09-15 16:10   ` Dora, Sunil Kumar
     [not found]   ` <18D58A6B209991A8.1909126@lists.openembedded.org>
2026-09-15 17:55     ` Dora, Sunil Kumar
2026-09-16  7:11   ` Antonin Godard
2026-09-21  9:46   ` Richard Purdie
2026-09-21 21:43     ` Alejandro Hernandez

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=20260915141834.1212812-5-sunilkumar.dora@windriver.com \
    --to=sunilkumar.dora@windriver.com \
    --cc=Randy.Macleod@windriver.com \
    --cc=alejandro@enedino.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=sundeep.kokkonda@windriver.com \
    /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