-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
Split each source code in test_crates/ into pair of crates #203
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to get some comments to you before it's too late in your timezone, and only managed to go through about half of this PR so far.
I'd highly recommend reading your own PR in the PR review interface. There are a bunch of things that stand out there that you probably wouldn't notice in your editor, and I bet you'll catch a number of issues and areas in need of polish and improvement by doing that. This is a high-risk PR since it changes so many things at once, and having more eyes reviewing it will also make it less likely that we end up with bugs as a result.
Co-authored-by: Predrag Gruevski <2348618+obi1kenobi@users.noreply.github.com>
Co-authored-by: Predrag Gruevski <2348618+obi1kenobi@users.noreply.github.com>
Merged |
Maybe it's better to move |
It might be beneficial to create the witness crates in a separate PR. |
Edit: done in 03c8333 I believe that |
@@ -0,0 +1 @@ | |||
pub struct CheckPubUseHandling; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I'm trying to understand what it's doing, it should be in a inner
mod?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, to mirror the old structure it should be in a pub mod inner
module and have a pub use
in lib.rs
.
Really this test doesn't need to have old/new versions. It's more just testing that re-exports are detected correctly — the re-exports are why this test case (which you said you were unsure about) exists and used to include multiple import paths for this CheckPubUseHandling
struct.
But there's no problem with having this in an old/new configuration as well. Just add the pub mod inner
and pub use
in both the old and the new crates, and we can test that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this what you had in mind, or should I also put all of the code into an inner crate, just like it was in the previous test structure? 0f9b7ec
I'd say move the contributing-specific information to What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, it's great: it has already helped flag multiple false-positive issues, and the test crate code is much more readable on account of not having to mess with features and conditional compilation.
I flagged a few minor things that should be easy to fix, and we need to remember to open a few GitHub issues so we don't forget to resolve the lint issues we've flagged. If you get a chance to open them — great! If not, I'll open them when it's not 1am over here 😴
scripts/regenerate_test_rustdocs.sh
Outdated
# Run rustdoc on test_crates/*/{new,old}/ | ||
for crate_pair in $(find "$TOPLEVEL/test_crates/" -maxdepth 1 -mindepth 1 -type d); do | ||
# Removing path prefix, leaving only the directory name without forward slashes | ||
crate_pair=${crate_pair#"$TOPLEVEL/test_crates/"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crate_pair=${crate_pair#"$TOPLEVEL/test_crates/"} | |
crate_pair="${crate_pair#"$TOPLEVEL/test_crates/"}" |
Should this be quoted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shouldn't this be quoted? Maybe the crate_pair
would have spaces in it, for whatever reasons. Though I hope that the quotation marks match with each other correctly in the old version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be quoted -- my suggested edit just wraps the whole thing in one extra set of quotes. That's just something I do obsessively in bash scripts since I've debugged several too many scripts where missing quotes either broke something (less bad option) or enabled script injection (much worse option). I just was wondering if adding the extra quotes might break something that I didn't notice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry, I've misunderstood. I thought you wanted to delete the quotes. I'll change it in a separate PR.
@@ -0,0 +1 @@ | |||
pub struct CheckPubUseHandling; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, to mirror the old structure it should be in a pub mod inner
module and have a pub use
in lib.rs
.
Really this test doesn't need to have old/new versions. It's more just testing that re-exports are detected correctly — the re-exports are why this test case (which you said you were unsure about) exists and used to include multiple import paths for this CheckPubUseHandling
struct.
But there's no problem with having this in an old/new configuration as well. Just add the pub mod inner
and pub use
in both the old and the new crates, and we can test that way.
Co-authored-by: Predrag Gruevski <2348618+obi1kenobi@users.noreply.github.com>
Co-authored-by: Predrag Gruevski <2348618+obi1kenobi@users.noreply.github.com>
Done.
I'll create the issues after merging this PR, to reference the exact lines of codes in the
Is there anything I've missed? |
Another idea I had for automating false-positive detection in the future: Some crates intentionally include items that are crafted as "bait" for false-positives, e.g. to act as regression tests for past false-positive issues. If we always place such "bait" in a dedicated file / module (e.g. Other crates are allowed to report on |
I hit a burst of productivity today, so I debugged and fixed all three false-positives, and opened the witness crates issue 🚀 |
Closes #144
Unfortunately this PR is a bit tedious to review, sorry.