Ensure that static initializers are acyclic for NVPTX #150569

kulst · 2026-01-01T19:51:45Z

Some targets (for now only NVPTX) do not support cycles in static initializers (see #146787). LLVM produces an error when attempting to codegen such constructs (like self referential structs).

This PR attempts to instead error on Rust side before reaching codegen to not produce LLVM UB.

This is achieved by computing a new query in rustc_const_eval. It is executed as a required analysis depending on a new flag in TargetOptions. The check

organizes all local static items in a DirectedGraph where pointers / references to other local static items represent the edges
calculates the strongly connected components (SCCs) of the graph
checks for cycles (more than one node in a SCC)

kulst · 2026-01-01T19:54:05Z

@rustbot label: +O-NVPTX

…this Some targets (for now only NVPTX) do not support cycles in static initializers (see rust-lang#146787). LLVM produces an error when attempting to codegen such constructs (like self referential structs). This PR attempts to instead error on Rust side before reaching codegen to not produce LLVM UB. This is achieved by computing a new query in rustc_const_eval. It is executed as a required analysis depending on a new flag in TargetOptions. The check 1. organizes all local static items in a DirectedGraph where pointers / references to other local static items represent the edges 2. calculates the strongly connected components (SCCs) of the graph 3. checks for cycles (more than one node in a SCC)

workingjubilee

Thanks for doing this. Haven't checked the logic closely yet.

View changes since this review

workingjubilee · 2026-01-01T20:52:43Z

compiler/rustc_target/src/spec/targets/nvptx64_nvidia_cuda.rs

            link_self_contained: LinkSelfContainedDefault::True,

+            // Static initializers must not have cycles on this target
+            requires_static_initializer_acyclic: true,


the word ordering is funny here. how about instead

Suggested change

requires_static_initializer_acyclic: true,

static_initializer_must_be_acyclic: true,

bjorn3 · 2026-01-01T21:01:38Z

compiler/rustc_interface/src/passes.rs

        });
    });
-
+    // NEW: target-gated pre-codegen error


Suggested change

// NEW: target-gated pre-codegen error

workingjubilee · 2026-01-01T21:04:54Z

compiler/rustc_const_eval/src/check_static_initializer_acyclic.rs

+    let mut statics: Vec<LocalDefId> = Vec::new();
+    for item_id in tcx.hir_free_items() {
+        let item = tcx.hir_item(item_id);
+        if matches!(item.kind, hir::ItemKind::Static(..)) {
+            statics.push(item.owner_id.def_id);
+        }
+    }


We don't mutate this after this part, right?

This can be something like

Suggested change

let mut statics: Vec<LocalDefId> = Vec::new();

for item_id in tcx.hir_free_items() {

let item = tcx.hir_item(item_id);

if matches!(item.kind, hir::ItemKind::Static(..)) {

statics.push(item.owner_id.def_id);

}

}

let statics: Vec<LocalDefId> = tcx.hir_free_items().filter_map(|item_id| {

let item = tcx.hir_item(item_id);

match item.kind {

hir::ItemKind::Static(..) => Some(item.owner_id.def_id),

_ => None,

}

}).collect();

Code that ends mut being available early is easier to read as you can stop scanning for mutation points in the function, even if it's a little more annoying to edit.

This general note applies to the rest of the file also.

kulst · 2026-01-01T22:05:45Z

Thank you for the reviews so far! I will address them over the next few days.

I am happy to receive comments and suggestions, especially since this is my first larger contribution to the compiler.

This is still an early version, but I wanted to ensure that my implementation does not negatively affect other components of the compiler. I also wanted to gather feedback on the general approach and the optimal location for this analysis within the code. I plan to add more tests and documentation as well.

On that note, would documenting this restriction inside the target description be sufficient? Is there a place to document nonconformity in general?

workingjubilee

Yes, I think that putting it in the platform support documentation would be fine. Or at least, I'm not aware of a better place at the moment.

View changes since this review

workingjubilee · 2026-01-01T23:02:44Z

compiler/rustc_const_eval/src/check_static_initializer_acyclic.rs

+        if nodes.is_empty() {
+            continue;
+        }
+
+        let is_cycle = nodes.len() > 1
+            || (nodes.len() == 1 && graph.successors(nodes[0]).any(|x| x == nodes[0]));
+        if !is_cycle {


Here we have three different cases: 0, 1, 2..

When we have exhausted all possibilities in a range like this, it's nice to make that clearly visible instead of requiring close attention to the particulars of each sub-expression.

That could be achieved by something like

let acyclic = match nodes.len() { 0 => true, 1 ==> !graph.successors.nodes([0]).any(x| x == nodes[0])), 2.. => false, } if acyclic {

workingjubilee · 2026-01-01T23:15:37Z

compiler/rustc_const_eval/src/check_static_initializer_acyclic.rs

+            GlobalAlloc::Static(def_id) => {
+                if let Some(local_def) = def_id.as_local()
+                    && let Some(&node) = node_of.get(&local_def)
+                {
+                    out.insert(node);
+                }
+            }


So we are going to insert into the StaticNodeIdx set, so that can't happen twice...

workingjubilee · 2026-01-01T23:18:43Z

compiler/rustc_const_eval/src/check_static_initializer_acyclic.rs

+        if !seen.insert(alloc_id) {
+            continue;
+        }
+
+        match tcx.global_alloc(alloc_id) {
+            GlobalAlloc::Static(def_id) => {
+                if let Some(local_def) = def_id.as_local()
+                    && let Some(&node) = node_of.get(&local_def)
+                {
+                    out.insert(node);
+                }
+            }
+
+            GlobalAlloc::Memory(const_alloc) => {
+                push_ptr_alloc_ids(const_alloc.inner(), &mut stack);
+            }


But here we have three sources of truth for what we have interacted with so far... and a fourth if we consider the hashmap that backs alloc IDs?

Do you think it would simplify things to use FxIndexSet and a counter, instead of a HashSet and Vec? At the very least, we're not saving ourselves much memory by using a transient Vec, because the HashSet for tracking what we've examined must continually grow anyways.

workingjubilee · 2026-01-01T23:20:17Z

compiler/rustc_const_eval/src/check_static_initializer_acyclic.rs

+            continue;
+        }
+
+        match tcx.global_alloc(alloc_id) {


This has some interesting documentation...

/// Panics in case the `AllocId` is dangling. Since that is impossible for `AllocId`s in /// constants (as all constants must pass interning and validation that check for dangling /// ids), this function is frequently used throughout rustc, but should not be used within /// the interpreter. pub fn global_alloc(self, id: AllocId) -> GlobalAlloc<'tcx> {

I see why you raised your concern about whether this is the best place for this code... I usually see target-based checks show up later, in rustc_monomorphize, but this is kinda special since it's about statics mostly, I guess, which are guaranteed monomorphization if they're included at all?

workingjubilee · 2026-01-01T23:48:00Z

tests/ui/static/static-initializer-acyclic-issue-146787.rs

It would be nice if this was a "minicore" test so we can run it on other hosts yet cross-target it for nvptx64, otherwise this test never runs.

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 1, 2026

rustbot added the O-NVPTX Target: the NVPTX LLVM backend for running rust on GPUs, https://llvm.org/docs/NVPTXUsage.html label Jan 1, 2026

This comment has been minimized.

Sign in to view

kulst force-pushed the check_static_initializer_acyclic branch from 10f31cc to 18143a8 Compare January 1, 2026 20:53

workingjubilee reviewed Jan 1, 2026

View reviewed changes

bjorn3 reviewed Jan 1, 2026

View reviewed changes

workingjubilee reviewed Jan 1, 2026

View reviewed changes

workingjubilee changed the title ~~Ensure that static initializers are acyclic for targets that require this~~ Ensure that static initializers are acyclic for NVPTX Jan 1, 2026

workingjubilee reviewed Jan 1, 2026

View reviewed changes

	requires_static_initializer_acyclic: true,
	static_initializer_must_be_acyclic: true,

Uh oh!

Ensure that static initializers are acyclic for NVPTX #150569

Are you sure you want to change the base?

Ensure that static initializers are acyclic for NVPTX #150569

Conversation

kulst commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kulst commented Jan 1, 2026

Uh oh!

This comment has been minimized.

workingjubilee left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

bjorn3 Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kulst commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

workingjubilee Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kulst commented Jan 1, 2026 •

edited

Loading

workingjubilee left a comment •

edited by rustbot

Loading

workingjubilee Jan 1, 2026 •

edited

Loading

kulst commented Jan 1, 2026 •

edited

Loading

workingjubilee left a comment •

edited by rustbot

Loading