Fix cast-lossless should not suggest when casting type is from macro input

[profetia]

Closes #15348

The span of the as expr is also incorrect, but I believe it is not a bug from Clippy.

changelog: [cast-lossless] fix wrong suggestions when casting type is from macro input

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[github-actions]

Lintcheck changes for 938e79f

Lint	Added	Removed	Changed
clippy::cast_lossless	0	202	3

This comment will be updated if you push new changes

[samueltardieu]

I am a bit puzzled by the proposed fix. For example, what should happen in the following case?

    macro_rules! zero {
        ($int:ty) => {{
            let data: [u16; 3] = [0, 0, 0];
            data[0] as $int
        }};
    }

    let _ = zero!(u8);
    let _ = zero!(u16);
    let _ = zero!(u32);
    let _ = zero!(u64);
    let _ = zero!(u128);

If Clippy gives a suggestion (as it does because of the u32, u64, and u128 cases) and the user applies it, then the code with u8 won't compile anymore. Isn't that dangerous to presume that the from() type relative function can be used just because one instance (or three in this case) appears to allow it?

[profetia]

In the proposed fix, no lint will be given for u8. When the casting type is from macro input, whether the cast is loseless become undermined. In this fix, a help is given instead of a suggestion. Maybe we should silence it all together?

[samueltardieu]

In the proposed fix, no lint will be given for u8. When the casting type is from macro input, whether the cast is loseless become undermined. In this fix, a help is given instead of a suggestion. Maybe we should silence it all together?

I think it should be silenced, because you cannot "fix" the macro if that could make some other uses of it not compile because of this fix.

[samueltardieu]

The span of the as expr is also incorrect

What do you mean?

[profetia]

@samueltardieu Updated. Now they are silenced.

[profetia]

The span of the as expr is also incorrect

What do you mean?

In the reproducer given in #15348,

The as span is showing as:

12 |           impl BitSplit for $int {
   |  ___________________________^
13 | |             type Half = $half;
14 | |             #[inline]
15 | |             fn merge(halves: [Self::Half; 2]) -> Self {
16 | |                 const HALF_SIZE: usize = std::mem::size_of::<$half>() * 8;
17 | |                 (halves[0] << HALF_SIZE) as $int | halves[1] as $int
   | |____________________________________________________________^

But it should be:

17 |                  (halves[0] << HALF_SIZE) as $int | halves[1] as $int
                                                         ^^^^^^^^^^^^^^^^^

This might be a bug in rustc

[samueltardieu]

The span of the as expr is also incorrect

What do you mean?

In the reproducer given in #15348,

The as span is showing as:

12 |           impl BitSplit for $int {
   |  ___________________________^
13 | |             type Half = $half;
14 | |             #[inline]
15 | |             fn merge(halves: [Self::Half; 2]) -> Self {
16 | |                 const HALF_SIZE: usize = std::mem::size_of::<$half>() * 8;
17 | |                 (halves[0] << HALF_SIZE) as $int | halves[1] as $int
   | |____________________________________________________________^

But it should be:

17 |                  (halves[0] << HALF_SIZE) as $int | halves[1] as $int
                                                         ^^^^^^^^^^^^^^^^^

This might be a bug in rustc

This might be fixed by rust-lang/rust#144711.