Properly ban the negation of unsigned integers in type-checking. #38776
Conversation
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
How complicated is it to retain the |
| //~^ ERROR E0080 | ||
| //~| unary negation of unsigned integer | ||
|
|
||
| -S; // should not trigger the gate; issue 26840 |
There was a problem hiding this comment.
This is a regression test for #26840. Perhaps should be retained in some way?
There was a problem hiding this comment.
Oh wait, what? Why is there a duplicate file?
There was a problem hiding this comment.
This is the problematic split. It has to do with how there's typeck, followed by lints and then followed by trans, and lints themselves can have these errors and optionally const eval warnings.
I think @oli-obk knows exactly why this was needed in the first place, but now there is no point.
|
@nagisa You'd want to do that on |
|
Travis error should be fixed by rust-lang/libc#484, in theory, waiting for a merge of that. |
|
@eddyb wrote:
Hmm, was PR #33401 expressive enough to cover this scenario? Update: maybe not; that may have been more about dealing with mismatches on type parameters other than |
|
Okay, I was worried at first when I saw the two tests being removed, but now I understand that there remains the variants that do not have the But ... @eddyb: shouldn't Update: @eddyb pointed out that this question didn't make sense. You can't bring back runtime tests of negating a |
Support Neg and Not in no_core mode. Needed by rust-lang/rust#38776 which requires the traits to be implemented even for integer types. This is already the case with binary operator traits, which always require the trait and its impls.
eddyb
force-pushed
the
unsigned-means-unsigned
branch
from
7047a8d
to
fbdadcb
Compare
|
r=me after travis passes. |
|
@bors r=pnkfelix |
|
📌 Commit fbdadcb has been approved by |
Properly ban the negation of unsigned integers in type-checking. Lint-time banning of unsigned negation appears to be vestigial from a time it was feature-gated. But now it always errors and we do have the ability to deref the checking of e.g. `-0`, through the trait obligation fulfillment context, which will only succeed/error when the `0` gets inferred to a specific type. The two removed tests are the main reason for finally cleaning this up, they need changing all the time when refactoring the HIR-based `rustc_const_eval` and/or `rustc_passes::consts`, as warnings pile up.
|
☀️ Test successful - status-appveyor, status-travis |
Lint-time banning of unsigned negation appears to be vestigial from a time it was feature-gated.
But now it always errors and we do have the ability to deref the checking of e.g.
-0, through the trait obligation fulfillment context, which will only succeed/error when the0gets inferred to a specific type.The two removed tests are the main reason for finally cleaning this up, they need changing all the time when refactoring the HIR-based
rustc_const_evaland/orrustc_passes::consts, as warnings pile up.