missing_transmute_annotations: No explanation for why missing input generic is bad

[tyilo]

Description

I just ran clippy on an old project where I have some code like:

use std::mem::{transmute, MaybeUninit};

struct Foo<T> {
    array: Box<[T]>,
}

impl<T> Foo<MaybeUninit<T>> {
    unsafe fn assume_init(self) -> Foo<T> {
        Foo {
            array: unsafe { transmute::<_, Box<[T]>>(self.array) }
        }
    }
}

The "Why is this bad?" section states:

If not set, some unexpected output type could be retrieved instead of the expected one, potentially leading to invalid code.

This is particularly dangerous in case a seemingly innocent/unrelated change can cause type inference to start inferring a different type. E.g. the transmute is the tail expression of an if branch, and a different branches type changes, causing the transmute to silently have a different type, instead of a proper error.

This explanation doesn't cover the case where the output type is specified but not the input type.

Either the description should be updated to explain why transmute::<_, T> is also bad or the lint should only apply when the output type is missing.

Version

rustc 1.80.1 (3f5fd8dd4 2024-08-06)
binary: rustc
commit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23
commit-date: 2024-08-06
host: x86_64-unknown-linux-gnu
release: 1.80.1
LLVM version: 18.1.7

Additional Labels

No response

[lukaslueg]

@rustbot claim

[alex-semenyuk]

@rustbot label A-documentation