Relax the need for "u" suffixes on uints under certain conditions.

[lkuper]

An attempt at Issue #1425. A more principled approach would have to
involve creating a new kind of type variable and doing unification on
those, separately from the existing type vars; this is more of a quick
hack.

Explaining the two tests I changed: It looks as though the
issue-1448-2.rs and issue-1362.rs tests were using unsuffixed integer
literals in a context that expected a uint, merely to trigger a
"mismatched types" error in the fastest way possible. So, we can just
replace the unsuffixed integer literal with a string.

[nikomatsakis]

Does it work for patterns?

My concern is that trying to infer in this way may just end up making things less predictable.

[graydon]

I am not really qualified to comment on the interaction with (say) coherence of the type inference algorithm, I defer to Niko on that. I would like to ensure the following though:

• that it works on patterns
• that it works for omitting any of the integer-suffix types
• that, as mentioned in the email above, it fails when the literal changes sign between signed and unsigned interpretations.

If this is a step towards those things, it's fine by me. If it's a step that'll only need to be undone to do those things in the more-principled manner, might be better to just start as you mean to go on.

[lkuper]

@graydon, @nikomatsakis Regarding patterns, you can do this:

  let x1 = 4u;

    alt x1 {
      1 to 2 { }
      3 to 4 { log(error, "hello") }
      _ { }
    }

But you can't do this:

  let x1 = 4u8;

    alt x1 {
      1 to 2 { }
      3 to 4 { log(error, "hello") }
      _ { }
    }

You would instead have to do

  let x1 = 4u8;

    alt x1 {
      1i8 to 2i8 { }
      3i8 to 4i8 { log(error, "hello") }
      _ { }
    }

which is not all that helpful, and so on for u16/i16, et cetera. That doesn't really do anything to solve the problem that @Jonanin describes in #1425 (comment) .

It handles all the signed int suffixes (no suffix/i8/i16/i32/i64) as though they had been the corresponding unsigned int suffix, if the corresponding unsigned int type is what the context expects. But as far as I can tell, the only case in which this is at all helpful is in the no-suffix case.

And, changing sign totally breaks things! Ugh. (And I honestly have no idea how to deal with that.) So forget this, it doesn't work. I was squeamish about it anyway.