feat: barely unusable → barely usable etc.#3774
Open
hippietrail wants to merge 3 commits into
Open
Conversation
Includes a new `strip_prefix_ignore_ascii_case_chars()` method on `&[char]`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Issues
N/A
Description
Somewhere yesterday I read where somebody wrote "barely un-adjective", I think "barely unusable".
My guess is this is a kind of overthinking mistake made by native speakers, it's very similar to a double negative and/or to an oxymoron. As if the writer is not sure whether to use "barely" or use the "un-" prefix and end up using both. It could be nonnative speakers with a poor understanding of how "barely" works. But from the examples I found they look more typical of native speaker errors to me.
I went with the
MiscellaneousLintKindas that's what theOxymoronslinter uses, which is pretty close to this one.This linter can be a good example for anyone that wants to incorporate a dictionary check in the "pattern" side of their linter rather than the
match_to_lintside. Closing withLrcis needed. I'd like @elijah-potter to double-check that logic too please.It also includes a new
strip_prefix_ignore_ascii_case_chars()method on&[char]. This is a method I've learned is quite valuable on strings and slices generally, but the ones in the standard library are not case insensitive and would require conversion/allocation with.to_lowercase()The dictionary is used to check that the word is an uninflected adjective both before and after removing the prefix, thus not blindly permitting
unique→nique. But there could be more subtle false positives where the result of stripping the prefix is still an adjective, but not the opposite of the original. I couldn't think of any.For now it only tackles the
un-prefix, but could be extended to supportim-,in-,de-,dis-- but some of those might involve more subtleties.Running the fuzzer on this would be appreciated!
How Has This Been Tested?
cargo testAI Disclosure
I asked Google Search AI for tips on getting the dictionary code in the pattern side working, and again to get my final working versions more rusty/more functional style.
If Your PR Implements or Enhances a Linter
Checklist