-
Notifications
You must be signed in to change notification settings - Fork 13.3k
An unused generic parameter should be a warning at the definition site. #34396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I actually implemented this lint in #26684! At the time, @alexcrichton was against the lint. |
I am not sure this would be useful - lints only execute after errors are reported. |
It looks like the compiler error only happens if the unused parameter is a type. If a lifetime is unused, there is no error or warning. For instance, https://is.gd/aFXcBf and https://play.rust-lang.org/?gist=5368c08fbdcba4efaa8c2e35aa59b429&version=stable&backtrace=0 really should trigger at least a warning. |
Dredging up this issue again. I would have liked a lint for unused lifetime parameters to be around for a PR on one of my libraries that removed a lifetime parameter from a struct, but not all of the functions that created it. If the parameter is completely unused, i don't want it appearing in my public API, and thus i would like to have a lint for it so i can keep that from happening. |
bumb In the following code, the fact that only #![allow(stable_features)]
#![feature(min_const_generics)]
fn foo<F>(x: i32) -> i32 { x }
fn bar<'a>(x: i32) -> i32 { x }
fn baz<const TOTO: i32>(x: i32) -> i32 { x }
fn reality_check(x: i32, y: i64) -> i32 { x }
fn main() {
bar(1);
foo::<f64>(3);
baz::<5>(4);
reality_check(99, -1);
} |
We should only emit a warning if the generic parater has no bounds, as code like |
We need a more in-depth discussion on this, something like #[allow(unused_variables)]
pub fn drop<T>(_x: T) {} |
The original report still errors, with a relatively good diagnostic (it could be better):
|
Consider the following code:
Currently, this causes a fatal compiler error at the invocation of
foo(4)
on line 9, of the form:The only way to ever successfully invoke
foo
is to feed it an explicit type (via the::<_>
syntax as illustrated on line 8).I suspect in many cases of this error, the actual problem is that the definition of
fn foo
(and alsofn bar
) are faulty: sinceF
and'a
are never referenced in the signature nor in the function body, they are irrelevant and should cause a warning via the compiler's linting system.(A separate issue is that one cannot actually instantiate the
'a
parameter tofn bar
via the::<_>
syntax, so it seems that its formal lifetime parameter is truly unusable. But things may not remain that way forever, so I think its best to lump both of these cases into the same category.The text was updated successfully, but these errors were encountered: