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 a1dfd24 to 98edd1f
regressed commit: 08e2d46

bisected with cargo-bisect-rustc v0.6.0

Host triple: aarch64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc

[Mark-Simulacrum]

Probably a duplicate of #79905

[matthewjasper]

#77638 maybe?

[jyn514]

#77638 was marked as wontfix: #77638 (comment). 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 #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]

• object-safe traits can have associated types with unchecked bounds #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.
• simple type inference fails depending on order of trait bounds #54121 was fixed. Some ambiguous method calls were being arbitrarily decided. Adding type annotations (often to specify the return type) will generally fix this.