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.

cc @RalfJung

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

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.

I will debug this later today but this is very weird

@rustbot ready

• 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)

@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?

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

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

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

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;
    }

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