You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I implemented the clear_with_drain Clippy lint for Vecs first, and then proposed to extend that to 5 other container types including Strings. However, in the process I realized that all my container types were diagnostic items except for Strings.
This led me to find a false negative in collection_is_never_read, which was also trying to check for Strings using is_type_diagnostic_item. The current workaround is to use the lang item for String, which means that this type gets a special treatment. I find this a little unfortunate and would like to be able to handle all these container types in the same way 🙂
@llogiq suggested to add a String diagnostic item here so I thought I would open the issue!
Ironically, the String type was the one mentioned as an example in @Manishearth's original proposal #39131, and it was again suggested in this comment. But apparently nobody needed this diagnostic item that bad!
Pros and cons
When working on Clippy lints, one expects the ability to check for such a prominent type using is_type_diagnostic_item, which can lead to false negatives (like I mentioned, even though this was also due to insufficient testing).
The only downside that I can think of is that there would be two different ways to check for the String type, so one can wonder which one one is supposed to use.
The text was updated successfully, but these errors were encountered:
Proposal
It would be nice if
String
was a diagnostic item.Background
I implemented the
clear_with_drain
Clippy lint forVec
s first, and then proposed to extend that to 5 other container types includingString
s. However, in the process I realized that all my container types were diagnostic items except forString
s.This led me to find a false negative in
collection_is_never_read
, which was also trying to check forString
s usingis_type_diagnostic_item
. The current workaround is to use the lang item forString
, which means that this type gets a special treatment. I find this a little unfortunate and would like to be able to handle all these container types in the same way 🙂@llogiq suggested to add a
String
diagnostic item here so I thought I would open the issue!Ironically, the
String
type was the one mentioned as an example in @Manishearth's original proposal #39131, and it was again suggested in this comment. But apparently nobody needed this diagnostic item that bad!Pros and cons
When working on Clippy lints, one expects the ability to check for such a prominent type using
is_type_diagnostic_item
, which can lead to false negatives (like I mentioned, even though this was also due to insufficient testing).The only downside that I can think of is that there would be two different ways to check for the
String
type, so one can wonder which one one is supposed to use.The text was updated successfully, but these errors were encountered: