You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following code compiles in 1.49 and newer (tested1.49 and two recent nightlies) but does not in 1.48 or older (easily testable with godbolt)
fnx<A,E>(_a:A) -> Result<(),E>whereA:T<E = E>{Ok(())}structX;traitT{typeE: core::fmt::Debug;}implTforX{typeE = ();}pubfnmain(){let a = X;x(a).expect("Practically it will work, but how might it fail?");}
with older versions giving "E doesn't implement Debug". It seems that in 1.49, the concrete E used as a consequence of how the X in a implements T is inferred by this version and used to satisfy the expect's requirement of implementing Debug.
I've gone through the change logs between 1.48 and 1.49, and nothing there hints at such behavior. If the change is unintentional, it should be known as a bug (because it'd produce regressions once it's flipped back). If it is intentional, it should be documented in the change log (can that be amended later on?) to make users with a keen eye for MSRVs aware it's there and compatibility with older versions can suffer (or I should get better at reading change logs).
The text was updated successfully, but these errors were encountered:
I had discarded that possibility when I saw that it happened after
1.48.0-beta.8, but looking at the dates now, it might easily just have
been the latest version at that point and they may indeed coincide.
The following code compiles in 1.49 and newer (tested1.49 and two recent nightlies) but does not in 1.48 or older (easily testable with godbolt)
with older versions giving "
E
doesn't implementDebug
". It seems that in 1.49, the concrete E used as a consequence of how the X in a implements T is inferred by this version and used to satisfy theexpect
's requirement of implementingDebug
.I've gone through the change logs between 1.48 and 1.49, and nothing there hints at such behavior. If the change is unintentional, it should be known as a bug (because it'd produce regressions once it's flipped back). If it is intentional, it should be documented in the change log (can that be amended later on?) to make users with a keen eye for MSRVs aware it's there and compatibility with older versions can suffer (or I should get better at reading change logs).
The text was updated successfully, but these errors were encountered: