Warn about unreachable code following an expression with an uninhabited type

[FabianWolff]

This pull request fixes#85071. The issue is that liveness analysis currently is "smarter" than reachability analysis when it comes to detecting uninhabited types: Unreachable code is detected during type checking, where full type information is not yet available. Therefore, the check for type inhabitedness is quite crude:

rust/compiler/rustc_typeck/src/check/expr.rs

Lines 202 to 205 in fc81ad2

	// Any expression that produces a value of type `!` must have diverged
	if ty.is_never(){
	self.diverges.set(self.diverges.get() | Diverges::always(expr.span));
	}

i.e. it only checks for !, but not other, non-trivially uninhabited types, such as empty enums, structs containing an uninhabited type, etc. By contrast, liveness analysis, which runs after type checking, can benefit from the more sophisticated tcx.is_ty_uninhabited_from():

rust/compiler/rustc_passes/src/liveness.rs

Line 981 in fc81ad2

let succ = ifself.ir.tcx.is_ty_uninhabited_from(

rust/compiler/rustc_passes/src/liveness.rs

Line 996 in fc81ad2

let succ = ifself.ir.tcx.is_ty_uninhabited_from(

This can lead to confusing warnings when a variable is reported as unused, but the use of the variable is not reported as unreachable. For instance:

enumFoo{}fnf() -> Foo{todo!()}fnmain(){let x = f();let _ = x;}

currently leads to

warning: unused variable: `x`
--> t1.rs:5:9
|
5 | let x = f();
| ^ help: if this is intentional, prefix it with an underscore: `_x`
|
= note: `#[warn(unused_variables)]` on by default
warning: 1 warning emitted

which is confusing, because xappears to be used in line 6. With my changes, I get:

warning: unreachable expression
--> t1.rs:6:13
|
5 | let x = f();
| --- any code following this expression is unreachable
6 | let _ = x;
| ^ unreachable expression
|
= note: `#[warn(unreachable_code)]` on by default
note: this expression has type `Foo`, which is uninhabited
--> t1.rs:5:13
|
5 | let x = f();
| ^^^
warning: unused variable: `x`
--> t1.rs:5:9
|
5 | let x = f();
| ^ help: if this is intentional, prefix it with an underscore: `_x`
|
= note: `#[warn(unused_variables)]` on by default
warning: 2 warnings emitted

My implementation is slightly inelegant because unreachable code warnings can now be issued in two different places (during type checking and during liveness analysis), but I think it is the solution with the least amount of unnecessary code duplication, given that the new warning integrates nicely with liveness analysis, where unreachable code is already implicitly detected for the purpose of finding unused variables.

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[estebank]

Suggested change

	ifletLiveNodeKind::ExprNode(succ_span, succ_id) = self.ir.lnks[succ]{
	self.warn_about_unreachable(
	expr.span,
	ty,
	succ_span,
	succ_id,
	"expression",
	);
	}elseifletLiveNodeKind::VarDefNode(succ_span, succ_id) = self.ir.lnks[succ]
	{
	self.warn_about_unreachable(
	expr.span,
	ty,
	succ_span,
	succ_id,
	"definition",
	);
	}
	matchself.ir.lnks[succ]{
	LiveNodeKind::ExprNode(succ_span, succ_id) => {
	self.warn_about_unreachable(
	expr.span,
	ty,
	succ_span,
	succ_id,
	"expression",
	);
	}
	LiveNodeKind::VarDefNode(succ_span, succ_id) => {
	self.warn_about_unreachable(
	expr.span,
	ty,
	succ_span,
	succ_id,
	"definition",
	);
	}
	_ => {}

[estebank]

Same as above, and given this is the second time you're doing this, maybe adding a method to LiveNodeKind might be warranted?

[estebank]

Is there a reason not to remove the current, existing, crude check in favor of this one?

[FabianWolff]

Yes, because type inference makes use of the crude divergence information available, e.g. here:

rust/compiler/rustc_typeck/src/check/fn_ctxt/checks.rs

Lines 654 to 660 in 5dc8789

	// Subtle: if there is no explicit tail expression,
	// that is typically equivalent to a tail expression
	// of `()` -- except if the block diverges. In that
	// case, there is no value supplied from the tail
	// expression (assuming there are no other breaks,
	// this implies that the type of the block will be
	// `!`).

The crude check is here:

rust/compiler/rustc_typeck/src/check/expr.rs

Lines 202 to 205 in 5dc8789

	// Any expression that produces a value of type `!` must have diverged
	if ty.is_never(){
	self.diverges.set(self.diverges.get() | Diverges::always(expr.span));
	}

Unfortunately, we can't replace it with tcx.is_ty_uninhabited_from() because type information has not been committed to tcx yet at this point.

[estebank]

I'm ok with the code changes, but left some questions.

[FabianWolff]

Thanks for your review and suggestions! I have slightly refactored the code now to implement your suggestions.

[Dylan-DPC-zz]

@estebank this seems ready for a final review

[jackh726]

@bors r=estebank,jackh726

[bors]

📌 Commit 7a98fd4 has been approved by estebank,jackh726

[bors]

⌛ Testing commit 7a98fd4 with merge 5ca596f...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank,jackh726
Pushing 5ca596f to master...

[rylev]

This change casued a very large regression in instruction counts. It seems to only be happening in one benchmark webrender-wrench and is consistently affecting the extern_crate, incr_comp_intern_dep_graph_node, and metadata_decode_entry_extern_crate queries in multiple test case variants of that benchmark. Given the nature of the change which only impacts liveness checking, I'm unsure why this might be the case. I was tempted to not report this, but given that the regressions are fairly large, I do think additional investigation is worth looking into.

As part of the performance triage process, I'm marking this as a performance regression. If you believe this performance regression to be justifiable or once you have an issue or PR that addresses this regression, please mark this PR with the label perf-regression-triaged.

@rustbot label +perf-regression

[Mark-Simulacrum]

This regression comes from a new unreachable expression warning specifically in webrender-wrench, which triggers the standard diagnostic infra. That infrastructure is pretty expensive, in this case loading up information from disk in order to trim paths being the most expensive bit.

As such, marking as triaged -- we expect performance to be worse when emitting extra diagnostics.

@rustbot label +perf-regression-triaged

[tamird]

This change seems to produce a warning even when no code follows the expression with the uninhabited type. e.g.

typeVoid = std::convert::Infallible;fnfoo() -> Result<Void,u64>{Err(5)}fnmain(){matchfoo().expect("should"){}}

in that code the match on the inhabited type is used to enforce a correctness property; should foo start returning a different type, we'd really like main to not type check.

This pattern is taken straight out of a blog post by @nikomatsakis.