Consider borrowing here: `&0`

[jjl]

error[E0308]: mismatched types
  --> src/schema_parser.rs:91:20
   |
91 |             if i < 0 {
   |                    ^
   |                    |
   |                    expected &i64, found integral variable
   |                    help: consider borrowing here: `&0`
   |
   = note: expected type `&i64`
              found type `{integer}`

What I actually wanted was *i.

[oli-obk]

The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of i being checked for PartialOrd and figuring out the the rhs needs to be of the same type.

Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.

[hellow554]

@jjl, can you please create a MCVE?

[csmoe]

@hellow554

fn main() {
    let i: &i64 = &1;
    if i < 0 {}
}

http://play.rust-lang.org/?gist=23f2d7858abee581e2cc0221fb67a7bc&version=nightly&mode=debug&edition=2015

[hellow554]

Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write

if i < &0 {}

and everything works just fine. Can you please explain this part (to me)?

[oli-obk]

The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort

[rakshith-ravi]

Resurrecting this.

@oli-obk what're the benefits of dereferencing the lhs instead of referencing the rhs?

Also, if I were to go about fixing this, where would I start?

[oli-obk]

The benefit is that x < y expands to Ord::cmp(&x, &y), so if you start out with x < &y you get Ord::cmp(&x, &&y), seems better to just do Ord::cmp(&*x, y) instead (since &* is a no-op that gets easily removed).

I'm not sure how to solve this or whether we should try at all.

[rakshith-ravi]

@rustbot claim