Repository navigation
regression 1.49: trait bound no longer inferred for associated type #79904
Description
[INFO] [stdout] error[E0277]: the trait bound `H: handle::ItemHandle` is not satisfied
[INFO] [stdout] --> src/property/property.rs:119:14
[INFO] [stdout] |
[INFO] [stdout] 119 | self.clone_as_trait()
[INFO] [stdout] | ^^^^^^^^^^^^^^ the trait `handle::ItemHandle` is not implemented for `H`
[INFO] [stdout] |
[INFO] [stdout] help: consider restricting type parameter `H`
[INFO] [stdout] |
[INFO] [stdout] 116 | impl<H: handle::ItemHandle> Clone for Box<dyn ResizeableProperty<Handle=H>>
[INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^
ResizeablePropertyHandle::Handle is constrained to implement handle::ItemHandle.
Other logs:
https://crater-reports.s3.amazonaws.com/beta-1.49-1/beta-2020-11-26/gh/Polkadex-Substrate.polkadex-engine/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.49-1/beta-2020-11-26/reg/actix-amqp-0.1.4/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.49-1/beta-2020-11-26/reg/ntex-amqp-0.1.20/log.txt
@rustbot modify labels: +regression-from-stable-to-beta
Activity
Mark-Simulacrum commentedon Dec 10, 2020
cc @nikomatsakis, @matthewjasper -- might this be related to #78893? It looks sort of "inverse" of that one I guess
rylev commentedon Dec 10, 2020
The
actix-amqpandntex-amqplogs also show another error (E0271). Perhaps these errors are related, but it's not easy to tell.dillona commentedon Dec 11, 2020
searched nightlies: from nightly-2020-09-24 to nightly-2020-12-11
regressed nightly: nightly-2020-10-07
searched commits: from a1dfd24 to 98edd1f
regressed commit: 08e2d46
bisected with cargo-bisect-rustc v0.6.0
Host triple: aarch64-unknown-linux-gnu
Reproduce with:
Mark-Simulacrum commentedon Dec 11, 2020
Probably a duplicate of #79905
matthewjasper commentedon Dec 11, 2020
#77638 maybe?
jyn514 commentedon Dec 16, 2020
#77638 was marked as wontfix: #77638 (comment). If this is the same issue, does it make sense to close it too?
rylev commentedon Dec 17, 2020
I'm surprised #77638 was marked as wontfix. This is a breaking change that seems to effect several real crates. While I admit I was surprised that this used to work (i.e., the current behavior makes more sense to me), I think we should confirm that how it's currently implemented in beta is how it's supposed to work.
rylev commentedon Dec 17, 2020
After discussion in Zulip, we decided to nominate this for discussion:
@rustbot label I-nominate
apiraino commentedon Dec 17, 2020
@rustbot label I-nominate
(let me try)
1 remaining item
matthewjasper commentedon Dec 18, 2020
Looking at this more closely, this is fallout from fixing #27675.
Mark-Simulacrum commentedon Dec 18, 2020
Okay, sounds like won't fix and that we should note the fix for #27675 as a compatibility note. Assigning to @XAMPPRocky to do so (and close this issue once you have done so).
XAMPPRocky commentedon Dec 23, 2020
Now in relnotes.
ibaryshnikov commentedon Jan 5, 2021
Can we have a summary of what happened? Or maybe a mention in the rust blog? After following through linked issues and pull requests I found a few mentions of security holes, but it's hard for me to reason about it. Some explanations from those who are more familiar with the topic would be much appreciated.
And what should I do with the code which compiled on stable rust 1.48.0 but stopped to compile on stable rust 1.49.0? Should I wait for a fix or rewrite it?
matthewjasper commentedon Jan 10, 2021
dyn Iterator<Item=T>) then adding the bounds to the parameter suggested by the compiler should fix it.Merge #686
Update lang/rust to version 1.49.0.
Update lang/rust to version 1.49.0.
Update lang/rust to version 1.49.0.
Update lang/rust to version 1.49.0.