paths, and construct paths for all definitions. Also, stop rewriting
DefIds for closures, and instead just load the closure data from
the original def-id, which may be in another crate.
Because of type inference, duplicate obligations exist and cause duplicate
errors. To avoid this, only display the first error for each (predicate,span).
The inclusion of the span is somewhat bikesheddy, but *is* the more
conservative option (it does not remove some instability, as duplicate
obligations are ignored by `duplicate_set` under some inference conditions).
Fixes#28098
cc #21528 (is it a dupe?)
Part of https://github.com/rust-lang/rust/issues/6993
This patch replaces `Ident`s with `Name`s in data structures of HIR and updates the dependent crates to compile and pass `make check`.
Some HIR structures still use `Ident`s, namely `PathSegment`, `PatIdent`, `ExprWhile`, `ExprLoop`, `ExprBreak` and `ExprAgain`, they need them for resolve (but `PathSegment` is special, see https://github.com/rust-lang/rust/issues/6993#issuecomment-141256292).
r? @nrc
Fixes#28279.
Currently
`common_supertype(*mut for<'a> Fn(&'a usize), *mut for<'a> Fn(&'a usize) + 'static)`
equals `*mut Fn(&usize)` which seems to be caused by `higher_ranked_sub()` allowing region variables to escape the comparison. This prevents inference from working properly with stuff like `Rc<Fn(&T)>`.
r? @nikomatsakis
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
The algorithm was not correctly detecting conflicts after moving
defaults into TypeVariableValue. The updated algorithm
correctly detects and reports conflicts with information about
where the conflict occured and which items the defaults were
introduced by. The span's for said items are not being correctly
attached and still need to be patched.
This patch allows type parameter defaults to influence type inference. This is a possible breaking change since it effects the way type inference works and will have different behavior when mixing defaults and literal fallback.
Correct regression in type-inference caused by failing to reconfirm that
the object trait matches the required trait during trait selection. The
existing code was checking that the object trait WOULD match (in a
probe), but never executing the match outside of a probe.
This corrects various regressions observed in the wild, including
issue #26952. Fixes#26952.
r? @eddyb
cc @frankmcsherry
the object trait matches the required trait during trait selection. The
existing code was checking that the object trait WOULD match (in a
probe), but never executing the match outside of a probe.
This corrects various regressions observed in the wild, including
issue #26952. Fixes#26952.
