Add `items_after_test_module` lint by blyxyas · Pull Request #10578 · rust-lang/...
source link: https://github.com/rust-lang/rust-clippy/pull/10578
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Collaborator
|
r? @dswij (rustbot has picked a reviewer for you, use r? to override) |
added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label
Contributor
|
|
The latest upstream changes (presumably Contributor
|
|
Contributor
|
|
Contributor
Author
|
Im thinking about removing suggestions. I could fix that case, but then if I put another item with an attribute over that one, it will break again. |
Contributor
|
|
force-pushed the items_after_test_module
branch
2 times, most recently
from
614e03e
to
4e91b2e
Compare
tests/ui/items_after_test_module.stderr
Outdated Show resolved
tests/ui/items_after_test_module.rs
Show resolved
declare_lint_pass!(ItemsAfterTestModule => [ITEMS_AFTER_TEST_MODULE]); |
||
impl LateLintPass<'_> for ItemsAfterTestModule { |
||
fn check_mod(&mut self, cx: &LateContext<'_>, _: &Mod<'_>, _: HirId) { |
Some style nit/suggestion dump, feel free to ignore 
Maybe we can take out the if_chain check, then do a skip_while iterator on items iter.
Member
Yeah, that sounds a bit convoluted. I'd recommend leaving the suggestion for now, and maybe come back to it in the future |
if_chain! { |
||
if was_test_mod_visited; |
||
if i == (items.len() - 3 /* Weird magic number (HIR-translation behaviour) */); |
Will this ever cause a panic? i.e. will items.len() < 3?
Contributor
Author
Just tested it with this code (The minimum amount of items that meats the requirements for the lint):
#[cfg(test)]
mod test {}
const U: usize = 0;
In an independent crate using this command: cargo dev lint ../<test dir>/ -- -- -W clippy::items_after_test_module --test
Even though the lint, well, lints. It doesn't overflow.
Member
|
Thank you! @bors r+ |
Commit 
Testing commit Contributor
|
|
Test failed - Member
|
@blyxyas Whoops, CI failed there. Can you help to take a look? |
Contributor
Author
|
I don't know how to fix this, it work on my machine and the normal Github CI test 'base'. Maybe retrying? |
Contributor
Author
|
@dswij Could you retry the bors tests? |
Member
|
@bors retry |
Contributor
|
|
Contributor
Author
|
??? It works on my machine, with a modern 64-bit Ubuntu-based OS, like the CI. I guess I'm going to ask on Zulip, because I can't replicate this CI |
Contributor
Author
|
It's fixed now, the bug was caused because the test didn't change to the |
Member
|
@bors r+ |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK