-
Notifications
You must be signed in to change notification settings - Fork 13.4k
rustc: Disallow autoderef for bottom type !
#14574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for looking into this! While this does indeed fix the ICE from appearing, it may not be the desired behavior that we want. In most other use cases the bottom type will unify and work with all other types. For example, if one branch of an The desired semantics here may be to "just work" and continue to propagate the bottom type outwards, but this is definitely another alternative! It may not matter too much in the long run because this seems pretty rare. |
I agree, propagating bottom seems like the more correct approach. |
cc me |
I am not sure if propagating bottom is good in this case. It makes sense in (some) other cases, because the semantics of what code would execute are not dependent on what type the |
To be honest, I actually wonder if we should include bottom in the type system at all. it is not particularly like other types. I think I would be happier overall if we just assigned the "type" |
On a short term basis, my patch fixes the ICE, so that might be desirable. On the other hand, it doesn't explain why the assumptions in middle/typeck/check/method.rs:confirm_candidate() are not satisfied (hence the bug() call). It may be a smell of some other failure not discovered yet, so I guess it needs to be addressed for the future. |
@nikomatsakis By "a fresh inference variable" do you mean that an expression typed as |
On Mon, Jun 02, 2014 at 01:05:44PM -0700, Kevin Ballard wrote:
Yes. This is what ML compilers do, afaik. |
Closing due to inactivity, but feel free to reopen with a rebase! |
internal: Make block_def_map infallible
Fix issue #13847.