Skip to content

Conversation

@ShoyuVanilla
Copy link
Member

cc #149973 (comment)

r? RalfJung
Sorry for bothering you, but I think it might be better to get the required MIR changes approved first, and then move on to implementing the actual lints for recursive static refs 😅

@rustbot
Copy link
Collaborator

rustbot commented Dec 19, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 19, 2025
let local_decl = LocalDecl::new(temp.ty, temp.source_info.span);
if temp.mutability == Mutability::Not { local_decl.immutable() } else { local_decl }
};
let new_temp = self.promoted.local_decls.push(new_local_decl);
Copy link
Member Author

@ShoyuVanilla ShoyuVanilla Dec 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wasn’t discussed in
#149973 (comment),
but I think it would be better to syntactically track promoted consts.

For example, the promoted const in the following code:

static FOO: () = {
    let _ = &&FOO;
};

is currently lowered to:

const FOO::promoted[0]: &&() = {
    let mut _0: &&();
    let mut _1: &();
    let mut _2: &();

    bb0: {
        _2 = const {alloc1: &()};
        _1 = &(*_2);
        _0 = &_1;
        return;
    }
}

I think it would make more sense for _2 to be immutable. This would also make it clearer when detecting &STATIC from:

_2 = const {alloc1: &()};
_1 = &(*_2);

It seems very unlikely that _2 would ever be truly mutable (for example, being reassigned with a different value), but anyway _2 being immutable gives some more assurance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants