-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Erroneous drop_bounds lint #86653
Comments
Hmm, I think a warning is still appropriate for this code, even if perhaps it's in a supoptimal place. |
For context, this code is used in a library that does deferred memory reclamation, so I want to store a heterogeneous collection of elements "to be dropped". I don't know what other type to use in that context than |
…eGomez Improve wording of the `drop_bounds` lint This PR addresses rust-lang#86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for rust-lang#86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound. There are two issues with the current warning message and lint description: - First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended. - Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not). cc `@jonhoo,` does this solve the issue for you? r? `@GuillaumeGomez`
Perhaps the standard library should provide an empty trait implemented by everything. ( |
I tried this code (playground):
I expected to see this happen: the code should compile without warning.
Instead, this happened: the compiler gave the following warning:
But, the
Drop
bound is not useless here — removing it causes the code to no longer compile. It's not clear if removing the bound should make the code stop compiling, but that's a different matter (and perhaps a different bug?).Meta
rustc --version --verbose
:The warning also occurs on nightly.
The text was updated successfully, but these errors were encountered: