librustc: Don't ICE when operator traits are not implemented properly. #12638
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Why does this have to change as well?
There was a problem hiding this comment.
Oh right, it's not related to this change but just a nit I forgot to fix way back when :P We don't need the if there since if !variadic then expected_arg_count == supplied_arg_count. Thus we can always just use expected_arg_count there.
There was a problem hiding this comment.
I'm not familiar with this code, so I don't know enough to confirm or deny this fact, but if you add an assertion that the two counts are the same then r=me
bors
added a commit
that referenced
this pull request
Mar 1, 2014
From my comment on #11450: The reason for the ICE is because for operators `rustc` does a little bit of magic. Notice that while you implement the `Mul` trait for some type `&T` (i.e a reference to some T), you can simply do `Vec2 {..} * 2.0f32`. That is, `2.0f32` is `f32` and not `&f32`. This works because `rustc` will automatically take a reference. So what's happening is that with `foo * T`, the compiler is expecting the `mul` method to take some `&U` and then it can compare to make sure `T == U` (or more specifically that `T` coerces to `U`). But in this case, the argument of the `mul` method is not a reference and hence the "no ref" error. I don't think we should ICE in this case since we do catch the mismatched trait/impl method and hence provide a better error message that way. Fixes #11450
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 25, 2022
Fix typo in build.rs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From my comment on #11450:
The reason for the ICE is because for operators
rustcdoes a little bit of magic. Notice that while you implement theMultrait for some type&T(i.e a reference to some T), you can simply doVec2 {..} * 2.0f32. That is,2.0f32isf32and not&f32. This works becauserustcwill automatically take a reference. So what's happening is that withfoo * T, the compiler is expecting themulmethod to take some&Uand then it can compare to make sureT == U(or more specifically thatTcoerces toU). But in this case, the argument of themulmethod is not a reference and hence the "no ref" error.I don't think we should ICE in this case since we do catch the mismatched trait/impl method and hence provide a better error message that way.
Fixes #11450