regression 1.49: trait bound no longer inferred for associated type

[rylev]

Log: https://crater-reports.s3.amazonaws.com/beta-1.49-1/beta-2020-11-26/gh/marcianx.openmesh-rs-core/log.txt

[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

[Mark-Simulacrum]

cc @nikomatsakis, @matthewjasper -- might this be related to #78893? It looks sort of "inverse" of that one I guess

[rylev]

The actix-amqp and ntex-amqp logs also show another error (E0271). Perhaps these errors are related, but it's not easy to tell.

[dillona]

searched nightlies: from nightly-2020-09-24 to nightly-2020-12-11 regressed nightly: nightly-2020-10-07 searched commits: from https://github.com/rust-lang/rust/commit/a1dfd2490a6cb456b92e469fa550dc217e20ad6d to https://github.com/rust-lang/rust/commit/98edd1fbf8a68977a2a7c1312eb1ebff80515a92 regressed commit: https://github.com/rust-lang/rust/commit/08e2d4616613716362b4b49980ff303f2b9ae654

bisected with cargo-bisect-rustc v0.6.0

Host triple: aarch64-unknown-linux-gnu Reproduce with: ```bash cargo bisect-rustc ```

[Mark-Simulacrum]

Probably a duplicate of https://github.com/rust-lang/rust/issues/79905

[matthewjasper]

77638 maybe?

[jyn514]

77638 was marked as wontfix: https://github.com/rust-lang/rust/issues/77638#issuecomment-708074295. If this is the same issue, does it make sense to close it too?

[rylev]

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]

After discussion in Zulip, we decided to nominate this for discussion:

@rustbot label I-nominate

[apiraino]

@rustbot label I-nominate

(let me try)

[Mark-Simulacrum]

@matthewjasper can you say whether you expect this to be fixable and backportable in time for the release on the 31st? It looks like a standard regression of inference to me, so maybe not too bad, but would be good to fix if possible. Maybe it is fixed by https://github.com/rust-lang/rust/pull/80132? I could see inference failing as a result of the change there to my naive glance :)

[matthewjasper]

Looking at this more closely, this is fallout from fixing #27675.

[Mark-Simulacrum]

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]

Now in relnotes.

[ibaryshnikov]

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]

• 27675 was fixed. Trait objects require that their associated types meet any bounds specified in the trait definition. If the associated type is specified is a type parameter (e.g. (dyn Iterator<Item=T>) then adding the bounds to the parameter suggested by the compiler should fix it.

• 54121 was fixed. Some ambiguous method calls were being arbitrarily decided. Adding type annotations (often to specify the return type) will generally fix this.