Fix #13140: Early/Late Bound related ICEs. #13157
Conversation
The problem was that we need to apply the substitution, so that the formal lifetime parameters get replaced with (unifiable) free-lifetimes that can actually be fed into the constraint solver. Also, refactor code os that substitution for `check_item` and `check_method`, moving both down the control flow into `check_bare_fn`. ---- Finally, there was another (similar) spot where we needed to substitute early-bound lifetimes when invoking an object method of a trait.
|
After more careful reading, I see that the path for objects is very special indeed. This should probably be refactored, but it was definitely already using a substituted type in the |
|
Any idea why bors has not picked this up yet? Is it offline? |
|
Sadly github orders commits chronologically rather than topologically, so the head commit didn't see the r+ :( |
r? @nikomatsakis Fix #13140 Includes two fixes, and a semi-thorough regression test. (There is another set of tests that I linked from #5121, but those are sort of all over the place, while the ones I've included here are more directly focused on the issues at hand.)
|
@alexcrichton wow that explains why github so often presents commits in an order opposite of what I expect to see That sounds a like a serious UX mismatch between bors and github. :( Thanks for taking care of this! :) |
|
@brson @alexcrichton actually I just thought of one potential thing that could help the UX issue here: perhaps the bors queue web page could present a link to the head commit in addition to its link to the PR itself? |
|
@pnkfelix yes great idea and easy. File a Bors issue? |
|
@brson will do |
|
filed as graydon/bors#29 |
…ype-path-with-coloncolon, r=jonas-schievink fix: Parse TypePathFn with preceding `::` e.g. `impl Fn::() -> ()`. Fixes rust-lang#13157. This was the problem, not that the path was not at the end. I could unify the parsing of `::` of TypePathFn with that of generic arg list, but some code relies on the `::` of generic arg list to be inside it.
Rustup r? `@ghost` changelog: none
…e-order, r=dswij `missing_trait_methods`: lint methods in definition order Lintcheck for rust-lang#13157 showed a bunch of changes for `missing_trait_methods` This is because `values_sorted` was sorting the entries by the key's [`DefPathHash`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.DefPathHash.html), this is stable for a given compiler but can change across versions changelog: none
r? @nikomatsakis
Fix #13140
Includes two fixes, and a semi-thorough regression test.
(There is another set of tests that I linked from #5121, but those are sort of all over the place, while the ones I've included here are more directly focused on the issues at hand.)