-
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
Make --cap-lints and related options leave crate hash alone #87145
Conversation
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
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.
This looks good to me, but I don't feel confident approving.
How eagerly are lints being checked? As in, if say lints are capped to allow, do the lints still get checked? Because if they don't, this might affect internal data structures, which in turn might affect details in the output. |
Yes. #74704 |
@est31 You mean in the rlib, or in the incremental db? |
@jsgf both actually? It might query things at a different point in time, which can influence how things are stored in internal caches. IIRC the rlib format just dumps many such internal data structures, but I'm not 100% sure. There should be no functional difference, but the resulting rlib files might have different hashes. This question is better answered by someone who knows this better than me. |
@est31 I see - having the rlib bitwise dependent on warning flags would certainly be very surprising. It doesn't seem to be the case for the limit tests I tried, but obv that's not a proof. But either way, if the crates are semantically identical then they can have the same crate hash even if the files are different bitwise (for example, cc @bjorn3 @Aaron1011 who have context from the last PR I put up along these lines. |
Mhh the |
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.
If running lints causes the build output (except diagnostics) to change that would be a bug IMO. Lints should only look and not touch anything. If cache state would affect the build output, that would be a bug in the incremental compilation system that may be exposed even without this PR.
📌 Commit 51142a0 has been approved by |
…laumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#86983 (Add or improve natvis definitions for common standard library types) - rust-lang#87069 (ExprUseVisitor: Treat ByValue use of Copy types as ImmBorrow) - rust-lang#87138 (Correct invariant documentation for `steps_between`) - rust-lang#87145 (Make --cap-lints and related options leave crate hash alone) - rust-lang#87161 (RFC2229: Use the correct place type) - rust-lang#87162 (Fix type decl layout "overflow") - rust-lang#87167 (Fix sidebar display on small devices) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Closes: #87144