Skip to content

lint unnecessary derefs #234

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

Closed
birkenfeld opened this issue Aug 25, 2015 · 7 comments · Fixed by #8355
Closed

lint unnecessary derefs #234

birkenfeld opened this issue Aug 25, 2015 · 7 comments · Fixed by #8355
Labels
A-lint Area: New lints E-hard Call for participation: This a hard problem and requires more experience or effort to work on T-middle Type: Probably requires verifiying types

Comments

@birkenfeld
Copy link
Contributor

I've seen uses of &*s where s is a String; this can be reduced to &s when calling a function that accepts &str.

Similarly, in the AST, I've seen (in clippy and racer) &**x or &*x where just x or &x is fine; call syntax will autoderef a &P<T> to a &T.

However, I don't really know yet how to do this in a general way.

@llogiq
Copy link
Contributor

llogiq commented Aug 27, 2015

I do have some instances of this in shadow.rs; however, I only added those because rustc would not compile it otherwise. Even knowing the general rules of auto-deref, I am not convinced I understand all the strange corner cases.

So unless we use a blacklist (same old, same old 😄), we'll have a real hard time trying to avert false positives.

@llogiq llogiq added E-hard Call for participation: This a hard problem and requires more experience or effort to work on T-middle Type: Probably requires verifiying types A-lint Area: New lints labels Aug 27, 2015
@birkenfeld
Copy link
Contributor Author

Yeah, as far as I understand it, the adjustment is done for function arguments and method/field lookup. But inner types are not adjusted, so once you have Option<P<...>> you need to do the dance manually.

This would have to check function arguments against the parameter types, and we'll have to find if rustc provides an API that does the "is type A compatible with type B after adjusting" check. If it doesn't, this is going to be hard :)

@llogiq
Copy link
Contributor

llogiq commented Aug 27, 2015

Agreed, you either end up building your own types at runtime (hard) or rewriting most of the type adjustment logic (probably harder).

@fpoli
Copy link

fpoli commented Aug 13, 2021

Even just supporting the case &*s where s is a String would be very useful. For new Rust users it's usually difficult to use the various string types correctly, and String is probably one of the most common types that implement a custom Deref.

@lengyijun
Copy link
Contributor

I wonder if &*String => &String is really good?
&*String always return &str
&String return &str or &String

@fpoli
Copy link

fpoli commented Aug 14, 2021

I wonder if &*String => &String is really good?
&*String always return &str
&String return &str or &String

That's a good point. The lint could be reported only if &*String expression is in the place of a method argument that requires &str.

@lengyijun
Copy link
Contributor

lengyijun commented Aug 16, 2021

let mut v=vec![];
// they are different!
v.push(s);
v.push(&**s); 

We need to ignore function with generic type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints E-hard Call for participation: This a hard problem and requires more experience or effort to work on T-middle Type: Probably requires verifiying types
Projects
None yet
4 participants