diff options
| author | Guillaume Gomez <guillaume1.gomez@gmail.com> | 2021-08-22 20:52:50 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-08-22 20:52:50 +0200 |
| commit | 2627db6a3cc4115cc3ff7a1597eb44347acb0c54 (patch) | |
| tree | c11313e20d1f9925e6dfc9dd3913cc193cefabbb /compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp | |
| parent | 7481e6d1a415853a96dcec11a052caaa02859b5a (diff) | |
| parent | 644529bdf133ce0f86dc93b4942f9d16960c84ea (diff) | |
| download | rust-2627db6a3cc4115cc3ff7a1597eb44347acb0c54.tar.gz rust-2627db6a3cc4115cc3ff7a1597eb44347acb0c54.zip | |
Rollup merge of #86747 - FabianWolff:issue-86653, r=GuillaumeGomez
Improve wording of the `drop_bounds` lint This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #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`
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
