Shifts shouldn't be tied to pointer-size integers

[pcwalton]

Let's fix this. Backwards-incompatible language/library change.

[tbu-]

@pcwalton Thank you for filing this bug, I totally forgot about the option of just filing a bug.

[nagisa]

Seems like this was introduced, at least in part, by #15407.

Shifting by an arbitrary unsigned integer sounds nice.

[nagisa]

Should be fixed by nikomatsakis@d803e22, which is part of #20754.

[tbu-]

@nagisa Doesn't look like it, this commit only touches the << syntax for primitive types, not their Shl implementation.

[nagisa]

@tbu- @nikomatsakis claims that traits are bypassed for primitive integer shifting, so I suppose the traits are there for documentation purposes. If you look at the tests added in the linked commit, shift operations should indeed support using any-sized integer as a right-hand size now.

We only need to update documentation to match the implemented behaviour.

[tbu-]

@nagisa It's true that they're bypassed for primitive integer shifting, but only as long as they aren't passed to generic code. The traits aren't a doc only issue in this regard.

[nikomatsakis]

Fixed in #20754

[nikomatsakis]

Specifically nikomatsakis@20744c6

[nikomatsakis]

On IRC, simukis points out that without suitable impls this is not 100% fixed, since shifts can't be as naturally used in generic code:

[09:18:08] <simukis> nikomatsakis: tbu- argues that your fix doesn’t apply for, uhm, generic code
[09:18:39] <simukis> something like fn `magic(a : T) where T: Shr { a << 10i8 }`
[09:18:59] <simukis> nmatsakis: ^
[09:19:15] <simukis> nmatsakis: this is re issue you just closed
[09:20:10] <simukis> though I have no idea how that would be implemented.
[09:21:03] <nmatsakis> simukis: ah, well, he's not wrong. we should probably add more impls.