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
In typeck passes, one often needs to do binary operations between two thingy: equality, substitution and what have you. A pattern has been adopted to handle that:
Unfortunately there are two interpretations of the signature, one is that the order of a and b is significant, the other insignificant. And the caller and callee seem to diverge.
For example, in librustc/middle/typeck/infer/mod.rs, there's honest one that says "I don't care about the value of a_is_expected":
It seems to use parameter a_is_expected, but only for error messages. The real deal trait_refs actually dictates a fixed order of a and b, which makes calling it like mk_sub_trait_refs(..., false, a, b) semantically wrong (it should be mk_sub_trait_refs(..., true, b, a)). Or rather, what caller expects is:
…tializer_can_be_made_const, r=Alexendoo
Rename thread_local_initializer_can_be_made_const to missing_const_for_thread_local
Closerust-lang#12934
As discussed at rust-lang#12934 name `thread_local_initializer_can_be_made_const` sounds against convention for other lints which describe the issue/wrong code but not suggestion and it is quite long. The new name take example from existing lint `missing_const_for_fn`
changelog: `thread_local_initializer_can_be_made_const` : Rename to [`missing_const_for_thread_local`]
In typeck passes, one often needs to do binary operations between two thingy: equality, substitution and what have you. A pattern has been adopted to handle that:
Unfortunately there are two interpretations of the signature, one is that the order of
a
andb
is significant, the other insignificant. And the caller and callee seem to diverge.For example, in
librustc/middle/typeck/infer/mod.rs
, there's honest one that says "I don't care about the value of a_is_expected":There's equality test that the order genuinely doesn't matter:
And then there's ambiguous one:
It seems to use parameter
a_is_expected
, but only for error messages. The real dealtrait_refs
actually dictates a fixed order ofa
andb
, which makes calling it likemk_sub_trait_refs(..., false, a, b)
semantically wrong (it should bemk_sub_trait_refs(..., true, b, a)
). Or rather, what caller expects is:I believe that's what leads to bugs like #12223.
So we should check and fix it, either by removing the
a_is_expected
all together or by rectifying the order ofa
andb
when it is used wrong.The text was updated successfully, but these errors were encountered: