I'd make an issue for it, but I first want to check if 1. it's actually possible (I don't know what kind of state clippy can and cannot account for), and 2. whether it's a good idea, or if there are situations unaccounted for that would make these undesirable.
At work I see a lot of string params used as a poor man's duck type. there are 4 scenarios I see regularly:
- The developer actually wants and needs a string or &str (least common)
- They want an enum (call sites are all checked against a finite number of values) (like compilation profiles)
- They want a new type wrapper (the string references an object which may be external to the program, such as a docker container or image) which may require coercing back to a string downstream
- They want another existing type (last second type conversion to a url or ip address or some other existing type).
4 seems like it would be the easiest (in terms of distance between param and action) and most sensible to be a clippy warning. DevEx wise, it makes sense to make conversion happen sooner rather than later, so that called function params provide compile time info on what the param actually is, where to find it, etc. you'd basically make it a warning so that they have to fix it at the lowest called function, then fix the warning in the callee function, all the way up to where ever that string either got instantiated passed, or where the logic stopped being specific to a type (like a function where more than one mutually exclusive conversion might happen, such as ipv4 vs ipv6)
2 would probably be way to expensive to do with clippy, since it's checking all call sites to see if it's basically a small set of equality checks, but may make sense for a SA tool like sonarqube
3 may be better as a suggestion, since it's not as straightforward to detect without noise.