Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add new lint
paths_from_format
#8833Add new lint
paths_from_format
#8833Changes from all commits
4596d61
6c2f56f
5a6ca6b
47e4a45
7980350
1a35d49
29384d7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this, I think it would be better to suggest
PathBuf
directly. Even if that might require additional modifications by the user.PathBuf
is intended for modifications as this one AFAIK :)Though, in that case we should have the applicability be less than machine applicable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, to clarify, you mean you want to do some or all of the following?
.join()
with.push()
Path::new
withPathBuf::from
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, if my comment wasn't clear. I mean a combination of the first two. So suggest
PathBuf::from()
and then add segments usingpush()
. The thing is, that this probably change the type of the buffer and require further adjustments by the user. Therefore, we should display the suggestion, but not make it machine applicable.Does this make sense, or should I try to describe it better? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking at the docs for
PathBuf
now, and I just realised that there might be a recommended solution for situations like this 😵💫.Functionally equivalent to
Will you be ok with this? Given it should still be machine applicable but I don't think it will have the same problems as before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to be careful when using the array as all the values have to be the same type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, this lint only checks for function calls, where the output is a
PathBuf
and the first argument is a format macro. The lint logic should also check the first value ofExprKind::Call
to ensure that it's a path to a function callednew
or other related function names.The logic should also contain a check if the code originated from a macro. I believe the check should be as simple as
!expr.span.from_expansion()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we maybe also check for calls to
Path::new
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the applicability is explicitly set with the lint emission, you can remove this value and all usages of it.
For
Sugg::hir_with_applicability
you can just useSugg::hir
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Formatting nit, as well as the other else cases in the
if_chain!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason, why you use two different methods to append text to an existing string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove the second part, as some users might not consider this more readable. The OS-agnostic part is also the main point, IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the comment in the related issue, I would actually think that such a paht can still be problematic. I'd suggest either, checking if the path starts with
//?/
which makes it a verbatim path under windows or (IMO the better approach) add a config value, to allow this. I have the feeling the lint can be very noisy without, but ignoring these cases can also be wrong.