-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Type inference regression in recent nightly #39984
Comments
Seems similar to #39808, in the sense that there is some unreachable code that apparently was used to help inference before? |
Diff between the I expect this was caused by #39485 (and thus is expected breakage?). |
Seems like it. |
Is it written somewhere what inference breaking was within range of "expected" and what is not? It started to bother me: the problem doesn't seem to be that some type info isn't available because it would be inferred from dead code. After all, the function signature here is not dead code, and everything's inferrable from there. The problem seems to be that the type of the dead expression isn't fully inferred from the non-dead code. But should the type of E matter since the code path is dead? And if it does, shouldn't it be fully inferrable from the function signature? |
Exactly. BTW, it's not convenient if dead code doesn't typecheck. It happens to me a lot when I'm writing new code, along with unused variables for example. |
As @nikomatsakis points out, existing code could be broken by doing proper type-checking in dead code. Ironic that disabling type checking of dead-code is actually causing type errors (this issue). I stand by my reasoning that dead code should be type checked (even if it breaks some existing code), however it would also make sense if the dead code warning was reported before errors in the dead code. |
So let me check: the recent changes disabled type-checking of dead code? And nevertheless it complains that the type of |
I'm not very familiar with how the compiler works, but I suspect the I'd rather someone who actually understands the compiler answer that question though... |
triage: P-high |
One of my crates is also experiencing this, with generated code similar to this (example heavily reduced):
Previously, this resulted in a dead code warning,
but now, it errors out:
This is although the type for |
I think this might be the same issue as #39808, although that one is tagged |
1.17 is now beta. |
So, is this issue considered a regression or a wontfix? |
Fix is enqueued. |
@sunjay done |
change the strategy for diverging types The new strategy is as follows. First, the `!` type is assigned in two cases: - a block with a diverging statement and no tail expression (e.g., `{return;}`); - any expression with the type `!` is considered diverging. Second, we track when we are in a diverging state, and we permit a value of any type to be coerced **into** `!` if the expression that produced it is diverging. This means that `fn foo() -> ! { panic!(); 22 }` type-checks, even though the block has a type of `usize`. Finally, coercions **from** the `!` type to any other are always permitted. Fixes rust-lang#39808. Fixes rust-lang#39984.
change the strategy for diverging types The new strategy is as follows. First, the `!` type is assigned in two cases: - a block with a diverging statement and no tail expression (e.g., `{return;}`); - any expression with the type `!` is considered diverging. Second, we track when we are in a diverging state, and we permit a value of any type to be coerced **into** `!` if the expression that produced it is diverging. This means that `fn foo() -> ! { panic!(); 22 }` type-checks, even though the block has a type of `usize`. Finally, coercions **from** the `!` type to any other are always permitted. Fixes #39808. Fixes #39984.
https://play.rust-lang.org/?gist=188e52dc2ba423a8f78c6e381f278cf1&version=nightly&backtrace=1
source (copied by @pnkfelix from gist linked above):
Maybe it's because
Ok(())
is unreachable?See rust-lang-deprecated/error-chain#132 for the original report.
The text was updated successfully, but these errors were encountered: