Skip to content
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

Negative numbers in types like-uint #5477

Closed
tredoe opened this issue Mar 21, 2013 · 20 comments
Closed

Negative numbers in types like-uint #5477

tredoe opened this issue Mar 21, 2013 · 20 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. P-low Low priority

Comments

@tredoe
Copy link

tredoe commented Mar 21, 2013

The compiler should show a warning message when is used a negative number into a like-uint type

let n: u8 = -1;
println!("{}", n); // => 255
@jdm
Copy link
Contributor

jdm commented Mar 21, 2013

Probably related to #2438.

@recrack
Copy link
Contributor

recrack commented May 7, 2013

Should this be done in typeck, or is it best done in lint?

@Aatch
Copy link
Contributor

Aatch commented Jun 7, 2013

Nominating for production-ready.

@msullivan
Copy link
Contributor

Yeah, I agree with that nomination.

@emberian
Copy link
Member

emberian commented Aug 8, 2013

This should really be a lint I think

@graydon
Copy link
Contributor

graydon commented Aug 8, 2013

Relative of #4220 and #5551 so probably milestone #1.

@graydon
Copy link
Contributor

graydon commented Aug 8, 2013

accepted for well-defined milestone

@pcwalton
Copy link
Contributor

Nominating because I believe we decided to not do this for negative numbers and the warning is already implemented for positive numbers. I think this can be closed.

@emberian
Copy link
Member

I think we should have a lint for bare -1 when it infers to an unsigned type, but -1u should be allowed. Generally I think the more-obvious construction !0, !0 - 1 etc should be used instead of negative literals.

@fhahn
Copy link
Contributor

fhahn commented Jan 19, 2014

Could this lint be combined with the type_overflow lint? The message of that lint ("literal out of range for its type") would fit in my opinion and and it shouldn't be too hard to extend the code of this lint.

@emberian
Copy link
Member

emberian commented Jul 3, 2014

I think at this point we've gone whole-hog on accepting that not warning on this is a feature. Nominating for closure.

@pnkfelix
Copy link
Member

pnkfelix commented Jul 3, 2014

Lints are not a language backwards-compatibility issue.

Recategorizing as P-low, not 1.0 milestone.

@mbrubeck
Copy link
Contributor

image-rs/image#305 is an example of a real-world bug that would have been caught by this warning. That bug involved code like std::iter::range_step(len, 0, -1) where len is unsigned.

@nagisa
Copy link
Member

nagisa commented Feb 28, 2015

@pnkfelix
Copy link
Member

pnkfelix commented Apr 2, 2015

see #23945; we're going further than a lint and moving to a feature-gate at this point.

The goals are two-fold:

  1. Removing unary-negation on unsigned integers does seem more consistent with our current overflow story, and
  2. if the community does strongly want -expr to work on unsigned integers, then this is a way to force the community to tell us. (Perhaps using stronger language than we might otherwise want, we shall see...)

@SiegeLord
Copy link
Contributor

Code like this compiles and runs without error in stable rustc today:

let a = -1; // 'a' gets inferred to u32, but the code compiles without error
let b: u32 = a;

Is the intention to stop that code from compiling or issue a runtime error?

@nagisa
Copy link
Member

nagisa commented Jul 13, 2015

Yes, although that would be somewhat of a breaking change.
On Jul 13, 2015 9:08 AM, "SiegeLord" [email protected] wrote:

Code like this compiles and runs without error in stable rustc today:

let a = -1; // A gets inferred to u32, but the code compiles without error
let b: u32 = a;

Is the intention to stop that code from compiling or issue a runtime error?


Reply to this email directly or view it on GitHub
#5477 (comment).

@pnkfelix
Copy link
Member

The intention was to force examples like above comment to be feature-gated (and thus you'd have to opt-in to be able to write them). But it seems like the feature-gating code in #23945 did not catch this case (or it has regressed since then, which seems less likely to me...)

@rnestler
Copy link
Contributor

@SiegeLord

let a = -1; // 'a' gets inferred to u32, but the code compiles without error
let b: u32 = a;

Gives a warning in stable and fails to compile in nightly for me on play.rust-lang.org

@steveklabnik
Copy link
Member

Yes, I would consider this fixed. The example is now fixed, it's behind a feature gate, and so when/if the gate is stabilized or removed, this will end up being discussed, so I think all of the concerns in this ticket are taken care of. Let me know if that's wrong!

oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. P-low Low priority
Projects
None yet
Development

No branches or pull requests