clippy's lint cast_lossless replaces macro invocation with macro definition.

[FractalFir]

Summary

Clippy failed with this output. I had cut out the irrelevant parts, since the output was very long (1522 lines). I can still provide it if necessary

    Checking rustc_codegen_clr v0.1.0 (/home/michal/Rust/rustc_codegen_clr)
warning: failed to automatically apply fixes suggested by rustc to crate `rustc_codegen_clr`

after fixes were automatically applied the compiler reported errors within these files:

  * src/codegen/place.rs
  * src/statement.rs

This likely indicates a bug in either rustc or cargo itself,
and we would appreciate a bug report! You're likely to see 
a number of compiler warnings after this message which cargo
attempted to fix but failed. If you could open an issue at
https://github.com/rust-lang/rust-clippy/issues
quoting the full output of this command we'd be very appreciative!
Note that you may be able to make some more progress in the near-term
fixing code with the `--broken-code` flag

The following errors were reported:
error: expected type, found `$`
  --> src/statement.rs:78:57
   |
78 |         Type::I8 => vec![BaseIR::LDConstI32(i32::from((<$dest>::from_ne_bytes(($var as $src).to_ne_bytes()))))],
   |                                                         ^ expected type

error: expected type, found `$`
  --> src/statement.rs:80:58
   |
80 |         Type::I16 => vec![BaseIR::LDConstI32(i32::from((<$dest>::from_ne_bytes(($var as $src).to_ne_bytes()))))],
   |                                                          ^ expected type

This seems to be the lint causing the issue:

warning: casting `i8` to `i32` may become silently lossy if you later change the type
  --> src/statement.rs:78:45
   |
78 |         Type::I8 => vec![BaseIR::LDConstI32(sign_cast!(scalar_u128, u8, i8) as i32)],
   |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `i32::from((<$dest>::from_ne_bytes(($var as $src).to_ne_bytes())))`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless

It seems like it does not respect boundaries of macros, replacing macro invocation with macro definition.

Reproducer

This is the relevant macro:

macro_rules! sign_cast {
    ($var:ident,$src:ty,$dest:ty) => {
        (<$dest>::from_ne_bytes(($var as $src).to_ne_bytes()))
    };
}

It is used here:

let scalar_u128 = match scalar {
        Scalar::Int(scalar_int) => scalar_int
            .try_to_uint(scalar.size())
            .expect("IMPOSSIBLE. Size of scalar was not equal to itself."),
        Scalar::Ptr(_, _) => todo!("Can't handle scalar pointers yet!"),
    };
    match scalar_type {
        Type::I8 => vec![BaseIR::LDConstI32(sign_cast!(scalar_u128, u8, i8) as i32)],
        Type::U8 => vec![BaseIR::LDConstI32(scalar_u128 as u8 as i32)],
        Type::I16 => vec![BaseIR::LDConstI32(sign_cast!(scalar_u128, u16, i16) as i32)],
        Type::U16 => vec![BaseIR::LDConstI32(scalar_u128 as i32)],
        Type::I32 => vec![BaseIR::LDConstI32(sign_cast!(scalar_u128, u32, i32))],
        Type::U32 => vec![BaseIR::LDConstI32(scalar_u128 as i32)],
        Type::F32 => vec![BaseIR::LDConstF32(f32::from_bits(scalar_u128 as u32))],
        Type::Bool => vec![BaseIR::LDConstI32((scalar_u128 != 0) as u8 as i32)],
        Type::I64 => vec![BaseIR::LDConstI64(sign_cast!(scalar_u128, u64, i64))],
        Type::U64 => vec![BaseIR::LDConstI64(scalar_u128 as i64)],
        Type::USize => vec![BaseIR::LDConstI64(scalar_u128 as i64)],
        Type::ISize => vec![BaseIR::LDConstI64(scalar_u128 as i64)],
        //Type::Enum(_) => vec![BaseIR::LDConstI32((scalar_u128 != 0) as u8 as i32)],
        _ => todo!("can't yet handle a scalar of type {scalar_type:?}!"),
    }

This is a part of my larger project. I had tagged the particular version of the source code that clippy had issues with.

Version

rustc 1.74.0-nightly (9f5fc1bd4 2023-09-02)
binary: rustc
commit-hash: 9f5fc1bd443f59583e7af0d94d289f95fe1e20c4
commit-date: 2023-09-02
host: x86_64-unknown-linux-gnu
release: 1.74.0-nightly
LLVM version: 17.0.0

Additional Labels

No response

[Centri3]

It looks like it gets the span of cast_op, but this is within the macro invocation. I think all we need to do is call source_callsite.