Handle field projections like slice indexing in invalid_reference_casting

[saethlin]

r? @Urgau

I saw the implementation in #124761, and I was wondering if we also need to handle field access. We do. Without this PR, we get this errant diagnostic:

error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused                                                                                
  --> /home/ben/rust/tests/ui/lint/reference_casting.rs:262:18                                                                                                                                                        
   |                                                                                                       
LL |         let r = &mut v.0;
   |                      --- backing allocation comes from here                                        
LL |         let ptr = r as *mut i32 as *mut Vec3<i32>;            
   |                   ------------------------------- casting happend here                                
LL |         unsafe { *ptr = Vec3(0, 0, 0) }                                                               
   |                  ^^^^^^^^^^^^^^^^^^^^                                                                 
   |                                                                                                       
   = note: casting from `i32` (4 bytes) to `Vec3<i32>` (12 bytes)     

[rustbot]

Failed to set assignee to Urgau: 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.

[saethlin]

Oh, that's unfortunate.

r? compiler

[Urgau]

Looks go to me. Thanks.

[Urgau]

When authoring #124761, I looked at every other ExprKind to see if I didn't missed another kind but found nothing suspicious, turn-out I did miss one, thanks for finding this one @saethlin.

Regarding the implementation, I wonder if we should turn the check into a allow instead of a disallow, that would avoid such issue in the future with new syntax or edge cases we have not yet found. Just an idea.

[saethlin]

Regarding the implementation, I wonder if we should turn the check into a allow instead of a disallow

This is a really good question. I've started doing a local crater run to look for other issues. Right now I'm leaning towards agreeing that we should invert the logic instead of trying to find all the cases where we need to bail. I'll try to post some kind of summarization of what I'm finding.

Is there a tracking issue for this lint? I feel like at this point it should have one, and a quick search for the lint name didn't find one.

[fee1-dead]

@bors r+ rollup

[bors]

📌 Commit 0ca1a94 has been approved by fee1-dead

It is now in the queue for this repository.

[Urgau]

Regarding the implementation, I wonder if we should turn the check into a allow instead of a disallow

This is a really good question. I've started doing a local crater run to look for other issues. Right now I'm leaning towards agreeing that we should invert the logic instead of trying to find all the cases where we need to bail. I'll try to post some kind of summarization of what I'm finding.

Great. I'm looking forward for that summary.

Is there a tracking issue for this lint? I feel like at this point it should have one, and a quick search for the lint name didn't find one.

No, there isn't, the lint was insta-stablized by T-lang in #111567. I would just create a issue for your summary.

[apiraino]

Beta backport accepted as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle.

@rustbot label +beta-accepted