Skip to content

Suggest str methods for trivial regexes #596

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
killercup opened this issue Jan 29, 2016 · 6 comments
Closed

Suggest str methods for trivial regexes #596

killercup opened this issue Jan 29, 2016 · 6 comments

Comments

@killercup
Copy link
Member

The contains and {starts,ends}_with methods of str can solve many simple regex cases.

cf. #587

@llogiq
Copy link
Contributor

llogiq commented Jan 29, 2016

As with the regex validation lint, the trick is using const_eval::eval_const_partial on the regex compile argument, and check for zero or one ^ at the beginning, zero or one $ at the end and characters without special regex meaning in between.

@llogiq
Copy link
Contributor

llogiq commented Jan 29, 2016

Also note that the following holds:

Start End String method/op
^ $ ==
$ .ends_with(_)
^ .starts_with(_)
.contains(_)

@llogiq
Copy link
Contributor

llogiq commented Feb 6, 2016

We could add suggestions taking the original str (beware of backslashes, though).

@llogiq
Copy link
Contributor

llogiq commented Feb 6, 2016

Speaking of backslashes, I found the following false negative:

    let trivial_backslash = Regex::new("a\\.b");
    //~^ERROR: trivial regex
    //~|HELP consider using `str::contains`

@mcarton
Copy link
Member

mcarton commented Feb 6, 2016

@llogiq I made a PR to fix that false negative. What kind of suggestion do you propose?

@llogiq
Copy link
Contributor

llogiq commented Feb 6, 2016

This would require using an ExprUseVisitor to find all usages of the regex and suggest using .contains("a.b") instead.

flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Aug 10, 2023
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP rust-lang#596.

We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.

Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).

We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants