Uh oh!
There was an error while loading. Please reload this page.
Track the finalizing node in the specialization graph - #70535
Conversation
Centril
commented
Mar 29, 2020
There was a problem hiding this comment.
A bit concerning that an inference context is needed for this. Shouldn't building the specialization graph also compute the necessary information to do this "more directly"? Or is this because of type parameters that are constrained by associated items?
There was a problem hiding this comment.
It looks like it kinda does, yeah. fulfill_implication is what needs the inference context since it unifies the impls, and it returns the Substs to rebase onto in translate_substs. It's also called when building the specialization graph, but there we just throw away the result. I'll look into storing the result, but I'm not sure I can figure out how everything works exactly.
There was a problem hiding this comment.
Hmm, this does not look straightforward, and I think I also lack some understanding about the type checker to do this.
There was a problem hiding this comment.
Seems fair, it's easier to infer everything through unification. I suppose the only thing that could be done ahead of time is to get the Substs for a less specialized impl, in terms of types from a more specialized impl.
That is, impl<T, U> Foo<U> for Vec<T> and impl<'a, X> Foo<() for Vec<&'a X> would give you Substs[&'a X, ()], and I guess if you had these on every edge in the specialization graph, you could walk "up" it (i.e. in the "less specialized" direction) by successive substitution.
Actually, is that what's necessary? Because it doesn't seem that hard to compute, you'd use translate_subst or w/e ahead of time and keep the result.
But it can be done in a separate PR.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
eddyb
commented
Mar 29, 2020
This comment has been minimized.
This comment has been minimized.
The generic parameter is unused, and so is `map`
Uh oh!
There was an error while loading. Please reload this page.
nikomatsakis
commented
Apr 1, 2020
@bors r+ |
bors
commented
Apr 1, 2020
📌 Commit fd8f818 has been approved by |
bors
commented
Apr 1, 2020
🌲 The tree is currently closed for pull requests below priority 500, this pull request will be tested once the tree is reopened |
…ikomatsakis Track the finalizing node in the specialization graph Fixesrust-lang#70419Fixesrust-lang#70442 r? @eddyb
Rollup of 6 pull requests Successful merges: - rust-lang#70535 (Track the finalizing node in the specialization graph) - rust-lang#70590 (Miri: make backtrace function names and spans match up) - rust-lang#70616 (rustc_target::abi: rename FieldPlacement to FieldsShape.) - rust-lang#70626 (cargotest: remove webrender) - rust-lang#70649 (clean up E0468 explanation) - rust-lang#70662 (compiletest: don't use `std::io::stdout()`, as it bypasses `set_print`.) Failed merges: r? @ghost
Fixes#70419
Fixes#70442
r? @eddyb