feat(utils/check_proc_macro): impl WithSearchPat for ast::Expr#15972
feat(utils/check_proc_macro): impl WithSearchPat for ast::Expr#15972ada4a wants to merge 3 commits into
impl WithSearchPat for ast::Expr#15972Conversation
| LitKind::Byte => (Pat::Str("b'"), Pat::Str("'")), | ||
| LitKind::ByteStr => (Pat::Str("b\""), Pat::Str("\"")), | ||
| LitKind::ByteStrRaw(0) => (Pat::Str("br\""), Pat::Str("\"")), | ||
| LitKind::ByteStrRaw(_) => (Pat::Str("br#\""), Pat::Str("#")), |
There was a problem hiding this comment.
| LitKind::ByteStrRaw(_) => (Pat::Str("br#\""), Pat::Str("#")), | |
| LitKind::ByteStrRaw(_) => (Pat::Str("br#"), Pat::Str("#")), |
| LitKind::ByteStrRaw(_) => (Pat::Str("br#\""), Pat::Str("#")), | ||
| LitKind::CStr => (Pat::Str("c\""), Pat::Str("\"")), | ||
| LitKind::CStrRaw(0) => (Pat::Str("cr\""), Pat::Str("\"")), | ||
| LitKind::CStrRaw(_) => (Pat::Str("cr#\""), Pat::Str("#\"")), |
There was a problem hiding this comment.
| LitKind::CStrRaw(_) => (Pat::Str("cr#\""), Pat::Str("#\"")), | |
| LitKind::CStrRaw(_) => (Pat::Str("cr#"), Pat::Str("#")), |
| ExprKind::Unary(UnOp::Not, e) => (Pat::Str("!"), inner(e, outer_span).1), | ||
| ExprKind::Unary(UnOp::Neg, e) => (Pat::Str("-"), inner(e, outer_span).1), | ||
| ExprKind::Lit(lit) => token_lit_search_pat(lit), | ||
| ExprKind::Paren(e) => inner(e, outer_span), |
There was a problem hiding this comment.
Let's imagine we have ([1, 2]). Wouldn't ExprKind::Paren(ExprKind::Array(…)) return ("[", "]")? Would that match?
There was a problem hiding this comment.
I think it would, because span_matches_pat trims parens before checking. The other places where this happens have the following comment:
// Parenthesis are trimmed from the text before the search patterns are matched.
// See: `span_matches_pat`I probably should add it here as well
Yeah you're probably right... but I put so much time into this, and it'd be a shame to let all that go to waste :( I would want to at least give an eventual implementer some hint about this PR existing, so that they know they don't need to start from scratch -- my idea would be to have a stub |
9d8a0f2 to
395cfe0
Compare
|
|
(sorry, didn't intend to close this) Yes of course, this must not be lost. Isn't there a place where this could be used (and tested)? |
Ah, good 😅
Now that you said it, yes, this could probably be added to a lot of early-pass lints as a |
395cfe0 to
54a84d5
Compare
This comment has been minimized.
This comment has been minimized.
|
So it turns out that the intersection of "early-pass lints" and "lints that check for any kind of expansion" was quite small, and so I only added the check in a couple lints.. hopefully that will be a good start |
54a84d5 to
2be9421
Compare
This comment has been minimized.
This comment has been minimized.
2be9421 to
e2ea611
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
e2ea611 to
fdfef98
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
☔ The latest upstream changes (possibly #16770) made this pull request unmergeable. Please resolve the merge conflicts. |
Extracted from #15939, which ended up not needing it.
changelog: none