Impl item removals should lint if the fallback item is not public API. #763
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.
Before this PR, the removal of the marked method in this snippet did not cause an
inherent_method_missing
lint:The reasoning was that the
impl Iterator
has a matching method andIterator
is in scope by default (assuming the prelude is used), so users of this code wouldn't get a compile error. Instead, they'd automatically fall back to theIterator::next()
method through the magic of Rust method resolution.With this PR, we improve the analysis for methods/associated functions and associated constants, so that cases like this do cause those lints — it'll now ignore trait implementations marked
#[doc(hidden)]
when considering if there's a valid fallback for the item that was removed.