-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Switch mutable_borrow_reservation_conflict
lint to deny by default
#76104
Switch mutable_borrow_reservation_conflict
lint to deny by default
#76104
Conversation
☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts. |
188ae3c
to
82833e0
Compare
The crater queue is pretty small, so let's kick off a run to see what the breakage looks like. @bors try |
⌛ Trying commit 82833e0 with merge b1cc2963e8346ba1f5afb1edb86dbcf3f9ef0c5f... |
☀️ Try build successful - checks-actions, checks-azure |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Yielding to a very small re-test of #76130 @craterbot retry |
🚨 Error: Experiment 🆘 If you have any trouble with Crater please ping |
🎉 Experiment
|
Hello @Aaron1011 and thank to have started the crater run. I looked at various regressions and they all seem legit. Unfortunately the 117 are individual regressions which mean there is not a handful of crate to fix but rather all of them. Unrelated question, for how long is the crater report going to be available for? |
@marmeladema: I'm not sure what amount of breakage is considered acceptable for this lint - @nikomatsakis or someone else should weigh in. @rust-lang/infra Are Crater reports hosted indefinitely? |
Yes. If we're going to ever start deleting them (which we don't plan to) we'll surely keep the past couple months of reports available. |
The lang team had agreed (described here) that we need to do a more thorough evaluation of the semantic models before we convert this to a hard error. I think several members of the lang team would be annoyed if we turned this into a hard error simply because "its been a warning for so long." We reached the compromise that we adopted in part because we promised we would not do that. |
(However, I'm also not sure whether turning this lint to deny-by-default needs to be coupled to turning on |
nominating for discussion at T-lang meeting, so that we can ponder when/if we are going to have time to do the follow-on work of evaluating semantic models et cetera that was promised here. |
I agree that we shouldn't just switch to deny just because time has passed. |
Yeah, taking another look I think this is right. I will note that the vast majority are GitHub repositories, many of which are advent of code or similar -- I think that likely means that the lint has indeed discouraged new uses of this pattern forming in code people are actively touching (unsurprisingly). It seems like all of the cases this lint touched that I saw in the code examples are quite simple and usually occur on just 1-4 lines without anything all that complicated in between (if anything), leading me to feel that in practice we're not likely to lose much without the definite aliasing information (since there's not much that could be done); furthermore I'd sort of expect that perhaps the aliasing information could be derived from the code in many cases as well through local analysis, even if it is not guaranteed by the language to always be there. Maybe I'm reading too much into these patterns though. I am also inclined to remove/silence this lint, personally. |
Update from @rust-lang/lang meeting: Last week @pnkfelix mentioned they'd look into some patterns. Removing nomination for now but we don't have agreement to go forward. |
@pnkfelix @nikomatsakis any update on this? I'm leaning towards closing this for now if @marmeladema and lang team is fine with this since it's been sitting around for sometime now |
No update as far as I know -- I am grateful to @marmeladema for preparing this PR -- closing is probably reasonable though, I think this isn't the major blocker for completing NLL. That said, we really should try to settle this question. It is going to be progressively more difficult to turn this lint into a hard error, which makes me wonder if indeed we even should. |
AIUI, the reason that this lint was not turned into an error for the 2021 edition is because it was decided that things like this can be done at any time, without an edition. If people are concerned that that would lead to too much breakage, then rather than close this entirely I'd prefer to just resubmit this as an item for a future edition. |
I think we should close this PR for now. The number of regressions is non-trivial and I am very interested in whether we can make this pattern be accepted by extending stacked borrows in some way (or perhaps our compilation into MIR). If not, I would be ok going forward, but it's obviously going to require a bit of a "phasing-in". |
Lint
mutable_borrow_reservation_conflict
was added about a year and a half ago in warning mode by default. Issue #59159 states that at some point, it should be set to deny by default which this PR implements.I am mainly creating this PR to start the discussion and try to help stabilizing full
nll
.I also don't know if we need a crater run for this kind of change?
Assigning to @pnkfelix because of the tracking issue but feel free to re-assign to whoever might be better suited to review this change.
r? @pnkfelix