Skip to content
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

Add a lint for unused type parameters #26684

Closed
wants to merge 1 commit into from

Conversation

sanxiyn
Copy link
Member

@sanxiyn sanxiyn commented Jun 30, 2015

Fix #25871.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -63,6 +63,7 @@
#![feature(no_std)]
#![no_std]
#![allow(raw_pointer_derive)]
#![allow(unused_type_parameters)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems weird that this is necessary? Where are things unused?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One example is core::intrinsics::size_of<T>.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, hm. Shouldn't extern fns with type params consider them used? (But, in general, it makes sense that there may be a few things like that.)

@alexcrichton
Copy link
Member

It looks like there's a number of legitimate use cases for having "unused" parameters, so can this be an allow-by-default lint instead of warn-by-default?

@sanxiyn
Copy link
Member Author

sanxiyn commented Jun 30, 2015

The reason this is a lint (and not a hard error, unlike struct S<T>) is because there are legitimate use cases. But they are rare, and in my opinion rare enough that writing #[allow(unused_type_parameters)] is acceptable.

@alexcrichton
Copy link
Member

I understand my viewpoint on whether lints should be warn by default is subject, by my believe is that any false positive on a lint means that it should not be warn-by-default. I've found that over time projects end up gaining dozens of little #[allow] directives that end up turning into spaghetti because each lint we have has very few false positives but the union of all the false positives means that you're going to have a lot.

@sanxiyn
Copy link
Member Author

sanxiyn commented Jul 1, 2015

This is not the first time you argued for allow-by-default. In #10477 you wrote:

There is a much larger use of #[allow(dead_code)] than I would expect throughout the codebase. I think this may be a sign that this should be an allow-by-default lint.

But dead_code lint was accepted warn-by-default. I am curious what changed your mind, because like @huonw on that thread, I think this should be warn-by-default.

@alexcrichton
Copy link
Member

This is not the first time you argued for allow-by-default.

I agree! I have historically been very anti-lints as I feel we have far too many already and generate too many warnings for false positives.

But dead_code lint was accepted warn-by-default. I am curious what changed your mind, because like @huonw on that thread, I think this should be warn-by-default.

Right, but that was almost two years ago. I would want it to be allow-by-default today.

@nikomatsakis
Copy link
Contributor

This is an interesting discussion. I wonder if we should adopt the convention that you can write _T: Foo to silence the lint, analogous with unused variables?

@bors
Copy link
Contributor

bors commented Aug 16, 2015

☔ The latest upstream changes (presumably #27818) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to resubmit with a rebase!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants