Note that the derive is only needed for assert_eq! to work properly.
Also note that try_into has no type argument (the type argument is part of the TryInto trait). So you cannot use try_into::<SomeType>(…). Instead I would use SomeType::try_from(…).
This looks like you've expecting the compiler to generate impl TryInto<T> for U where you have impl TryFrom<T> for U. But this is impossible in general - trait implementation can be arbitrary complex, it can't be reversed automatically.
I think that bug / feature request only refers to the wording of the error message (complaining that it proposes to implement From, while it would be sufficient to implement TryFrom)
Generally, I would agree to what @Cerber-Ursi said:
That's not correct. The blanket Into (and TryInto) impl doesn't (and can't) perform the inverse of the From (or TryFrom) it refers to. In other words, Into<U> for T is implemented if U: From<T>, an markedly not if T: From<U>.
Into is merely meant to work as syntactic sugar in contexts where a method call looks prettier than spelling out the full UFCS syntax, i.e. something.into() rather than OtherThing::from(something). As others have already pointed out, it's not possible to automatically find an inverse of these conversions in general.
The question is, what we can try to do? There're no "matching rules" in general case, and Rust will not analyze the function bodies anyway (since this approach will be too fragile).
Language features of the form “I have no idea how that works, but it works” are always a problem. They may look nifty in the short-term, but medium term they become a liability.
Because if you don't know how something works then you don't have any idea when it wouldn't work. Or work in a strange way.
That's how PHP ended up with an equality operator which boldly proclaims that strings "1e3" and "1000" are equal.
I'm just saying that if you compare two strings (e.g. two inventory ids) you wouldn't expect "1e3" and "1000" to be considered equal.
And sure, I can use === in Javascript or PHP to get predictably-working program but this just doesn't make much sense: why have some feature in a language if the only thing you need to know about it is to never use it?