diff options
| author | Guillaume Gomez <guillaume1.gomez@gmail.com> | 2021-10-08 22:30:38 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-10-08 22:30:38 +0200 |
| commit | 32502404e5ed78b927cc9807eac0cf6cd3623450 (patch) | |
| tree | b30def107f10609fe81c12f2ad5911446f5b1c72 /src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | 87df4dd70f13f248a4d2d22cdd96ee59d161d741 (diff) | |
| parent | 3215403dde605b310826d8985261d8eeed3ea983 (diff) | |
| download | rust-32502404e5ed78b927cc9807eac0cf6cd3623450.tar.gz rust-32502404e5ed78b927cc9807eac0cf6cd3623450.zip | |
Rollup merge of #86506 - b-naber:gen_trait_impl_inconsistent, r=jackh726
Don't normalize xform_ret_ty during method candidate assembly Fixes https://github.com/rust-lang/rust/issues/85671 Normalizing the return type of a method candidate together with the expected receiver type of the method can lead to valid method candidates being rejected during probing. Specifically in the example of the fixed issue we have a `self_ty` of the form `&A<&[Coef]>` whereas the `impl_ty` of the method would be `&A<_>`, if we normalize the projection in the return type we unify the inference variable with `Cont`, which will lead us to reject the candidate in the sup type check in `consider_probe`. Since we don't actually need the normalized return type during candidate assembly, we postpone the normalization until we consider candidates in `consider_probe`.
Diffstat (limited to 'src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions