Allow &raw [mut | const] for union field in safe

[Kivooeo]

fixes #141264

r? @Veykril

Unresolved questions:

• Any edge cases?
• How this works with rust-analyzer (because all I've did is prevent compiler from emitting error in &raw context) (Allow &raw [mut | const] for union field  rust-analyzer#19867)
• Should we allow addr_of! and addr_of_mut! as well? In current version they both (&raw and addr_of!) are allowed (They are the same)
• Is chain of union fields is a safe? (Yes)

[rustbot]

Failed to set assignee to Veykril: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[jieyouxu]

cc @RalfJung

[RalfJung]

Uh, the unsafety checker is not actually code I know very well, sorry.
r? compiler

[RalfJung]

Should we allow addr_of! and addr_of_mut! as well? In current version they both (&raw and addr_of!) are allowed

The macros just expand to &raw, it's not even possible to treat them differently.

[Kivooeo]

I will debug this later today but this is very weird

[Kivooeo]

@rustbot ready

[Veykril]

As was brought up in the zulip thread, there should probably be a test for raw borrowing a union field in a closure capture like || &raw u2.a or so. Iirc the question there was whether the closure captures u2 (which would be fine), or u2.a (which would itself still be unsafe as its a read, be it a borrow or move/copy).

[Veykril]

• How this works with rust-analyzer (because all I've did is prevent compiler from emitting error in &raw context)

rust-analyzer has its own unsafety check here: https://github.com/rust-lang/rust/blob/46264e6dfd8f0bacae05c520b4617e054d6ef990/src/tools/rust-analyzer/crates/hir-ty/src/diagnostics/unsafe_check.rs

with tests living here https://github.com/rust-lang/rust/blob/46264e6dfd8f0bacae05c520b4617e054d6ef990/src/tools/rust-analyzer/crates/ide-diagnostics/src/handlers/missing_unsafe.rs

If you can look into that together with this PR that would be appreciated, but if not that's also okay (iirc you can't really run specific tests for r-a in the rust repo yet, correct me if I am wrong @jieyouxu)

[Kivooeo]

@Veykril

Iirc the question there was whether the closure captures u2 (which would be fine), or u2.a (which would itself still be unsafe as its a read, be it a borrow or move/copy)

In current state this is not emitting error, but, I'm unsure if it should, this is pretty tricky quesiton I have no answer for, this is actually my first interaction with unions :)

rust-analyzer has its own unsafety check here

Sure! I will check it, would it be better to open PR (if I found a way to fix this or just issue if not) in RA's repo?

[Veykril]

Sure! I will check it, would it be better to open PR (if I found a way to fix this or just issue if not) in RA's repo?

It would probably be easier to work in the rust-analyzer repo directly yes

[Kivooeo]

I will try to found out what exactly closure captures later today, I guess that MIR or HIR could show me this information

[RalfJung]

@lcnr @compiler-errors do you know the intended spec for closure captures around unions? We never do field capturing there, do we?

[Kivooeo]

Well, if I get this right, this capturing all union

bb0: {
        _1 = U { a: const 42_i32 };
        _3 = &_1;
        _2 = {closure@/Users/meow/projects/wtf/src/main.rs:10:13: 10:15} { u: move _3 };
        return;
    }

[compiler-errors]

We truncate precise captures of union fields to the whole union here:

rust/compiler/rustc_hir_typeck/src/upvar.rs

Lines 2155 to 2157 in 95a2212

	if place.base_ty.is_union() {
	truncate_place_to_len_and_update_capture_kind(&mut place, &mut curr_mode, 0);
	}

[Kivooeo]

@compiler-errors, hope you dont mind the ping! the needs-fcp label is a bit unclear to me, because it feels like we are waiting for something, but im not sure what exactly

id really appreaciate it if you could clarify this when you have a momemtn

[jieyouxu]

If you can look into that together with this PR that would be appreciated, but if not that's also okay (iirc you can't really run specific tests for r-a in the rust repo yet, correct me if I am wrong @jieyouxu)

You're not wrong. I haven't hooked up main r-a tests yet because I'm waiting for the staging changes (the stage 0 redesign) to avoid making that effort more complicated.

[wesleywiser]

Hi @compiler-errors, I think this is ready for another review (or perhaps to start a T-lang FCP?) when you get a chance. Thanks!

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[Kivooeo]

changed because it is not an unsafe operation anymore