-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Don't lint assertions_on_constants
on any const assertions
#12840
base: master
Are you sure you want to change the base?
Conversation
error: `assert!(true)` will be optimized out by the compiler | ||
--> tests/ui/assertions_on_constants.rs:49:19 | ||
| | ||
LL | const _: () = assert!(true); |
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 intended to affect those that are not explicitly a block? i.e. inside {}
?
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, it is intended. The lint now doesn't fire on any const-assertions.
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.
We could catch the true
literal value. As it sems like a programming typo?
Happy to hear your thoughts on this?
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.
assert!(true)
isn't much use, and is linted by assertion_on_const
for that reason.
Looking at #12816, why do we want to skip linting assert!(8 == (7+1));
? Is there a scenario where checking 8 == 7+1
makes sense?
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.
8 == 7+1
is just an illustration for simple cases. It could be a more complex expression, like checking layout equality of different types. But I don't think checking if expressions is simple or complex is worth the complexity.
Also with the case of 8 == 7+1
get a typo, we have a compile-time panicking. So asserting 8 == 7+1
in const context is kinda worth it.
So maybe I could add a comment about this in test file?
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.
It's done by a0234b4
assertions-on-constants
when it is const assertionsassertions-on-constants
on any const assertions
It's been 2 weeks without new review |
e6cb5a2
to
7b06d72
Compare
Build fail as expected. In summary: So waiting for next rustup... Edit: |
- remove now dead code in ASSERTIONS_ON_CONSTANTS cc rust-lang#11966 - Partially revert "ignore `assertions-on-constants` in const contexts" This reverts commit c7074de.
rerolling r? @llogiq |
Looks ok to me. Thank you for staying the course. @bors r+ |
💔 Test failed - checks-action_test |
Blessed the test after rustup ! |
assertions-on-constants
on any const assertionsassertions_on_constants
on any const assertions
changelog: Don't lint
assertions_on_constants
on any const assertionschangelog: fix false-positive of
unnecessary_operation
lint in const contexts.close #12816
close #12847
cc #12817