The previous implementation was not very clear, this commit attempts to clarify and clean up the code that
applies all defaults.

Thanks to @eddyb for bringing this bug to my attention.

infer/mod.rs, infer/type_variable.rs and error.rs were manually rebased
due to being moved from librustc/middle/infer/ to librustc/infer

Had screwed up the rebase of `check/mod.rs`. The error handling code is
commented out because I don't know how to rebase it.

User fallbacks are applied as a last ditch attempt at inference.
If a type variable could gain a fallback in the future, it may not
unify with anything, for future-proofing. This means adding a default
is always backwards-compatible.
Check `apply_user_type_parameter_fallback` for the algorithm.

…entation.

Regression fixed by reverting from rebased version to
`default_type_parameters` in master.
Renamed it to `apply_diverging_and_numeric_type_parameter_fallback`.
Removed the previous algorithm for user fallback.

The origin of the type parameter had to be plumbed down to typeck,
maybe there is a better way to do it?

We use the default information in TypeVariableData. Also improved some
comments.

Fixes bug with default fallback, and small refactorings to default
fallback.

The happy kind of test.

…sts.

The tests under bad_messages in ui are the ones that have bad messages
that need fixing.

We only demand equality when we are sure now, fixing bad error
messages. We also skip a priority level if we detect a conflict, an
improvement over the previous algorithm. But there is a bug related to
normalizing dependent defaults, see FIXME.

Since this means there are cross-bag dependencies, we use a fixed point
algorithm, looping over the bags until we can no longer solve any of
them.

While this was future-proof wrt API evolution, it is not future proof
wrt to compiler evolution, such as making priority levels more
fine-grained or just fixing bugs. It's a not very useful behavior and a
complexity this feature doesn't need.

Refactored the fallback algorithm to be simpler.

Just fails on conflicting defaults.

I tried preventing having to rollback inference and being clever with
sty equality, but dependent defaults means we need full inference here.

All application of defaults goes in the same transaction, again because
of dependent defaults. We can't mess with the fulfillment context in a
snapshot, so we clone our own fulfillment context.

The downside is that if we fail one bag we fail all, which can be very
confusing as the user may be presented with several errors when only
one of them is the "real one".

This is not so bad because we may easily have a heuristic that solves
the bags that can be solved in isolation and then puts the complicated
cases in a single transaction, making the pathological situation quite
rare.

Make test more focused, and clarify what the bug is. Add new ui test.

I don't know if it's what we want but it's how it works now. If we want
to keep it then we should forbid writing the default in the impl.

…rred

Makes associated types in defaults less verbose.

If you propagate the origin, you propagate the default. Fixes fallback
for field access.

Also small refactoring in combine.

…context"

Try fallback right in `structurally_resolve_type_or_else` right before
we hit "the type of this value must be known in this context".

This gets casts working, and probably other things not tested for.

Also remove some dead code.

It seems we have pretty much the same logic in three different places,
so it was fixed in three different places. Took the opportunity to
leave FIXMEs regarding elision of defaulted params.