-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loop over all opaque types instead of looking at just the first one with the same DefId #87107
Conversation
| | ||
LL | fn cool_fn<'a>(arg: &'a str) -> OpaqueOutputImpl<'a> { | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR is great to me, we've discussed this with Oli already. I'm not strong enough to approve in particular this part of the PR. cc @nikomatsakis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The span here is kind of confusing. I suppose we want to be pointing to the binding?
Assigning to Niko, based on my comment above. |
@@ -12,6 +12,7 @@ trait Output<'a> {} | |||
impl<'a> Output<'a> for &'a str {} | |||
|
|||
fn cool_fn<'a>(arg: &'a str) -> OpaqueOutputImpl<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is kind of weird. Does it pass if the let out: ...
is removed?
I expect it to pass, because we stabilized member constraints in #84701, but it seems like the let out: ...
is probably caused it not to work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is kind of weird. Does it pass if the
let out: ...
is removed?
yes, it does. Note that this test has impl_trait_in_bindings
enabled, so it's not really relevant for min_tait. The problem is that the let binding gives us
expected
&'<empty> str
, got&'a str
which is probably due to the odd way that impl_trait_in_bindings
works and that should hopefully all go away once we do not treat them special anymore and just put them into the inference list just like we do with the return type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is really weird, we were talking about it with @lqd some minutes ago.
Note the following https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3c4de7d1bfdfee59d8e2f3f5c0d39453
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd merge this as is, in my remove let binding PR this test is going away anyway so ...
@bors r+ |
📌 Commit 587e8fd has been approved by |
Loop over all opaque types instead of looking at just the first one with the same DefId This exposed a bug in VecMap and is needed for rust-lang#86410 anyway r? `@spastorino` cc `@nikomatsakis`
…laumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#87107 (Loop over all opaque types instead of looking at just the first one with the same DefId) - rust-lang#87158 (Suggest full enum variant for local modules) - rust-lang#87174 (Stabilize `[T; N]::map()`) - rust-lang#87179 (Mark `const_trait_impl` as active) - rust-lang#87180 (feat(rustdoc): open sidebar menu when links inside it are focused) - rust-lang#87188 (Add GUI test for auto-hide-trait-implementations setting) - rust-lang#87200 (TAIT: Infer all inference variables in opaque type substitutions via InferCx) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This exposed a bug in VecMap and is needed for #86410 anyway
r? @spastorino
cc @nikomatsakis