Do not discern between statements with and without semicolon after lowering to HIR

[petrochenkov]

In AST we need to discern between statements with semicolon and statements without semicolon in a block to detect the block's "trailing expression" (which may end up trailing after macro expansion, but start somewhere in the middle of the block, see the in-progress issue #61733).

After the trailing expression is detected during lowering to HIR, the distinction is no longer necessary...

... with exception of one surprising corner case that I discovered today:

fn main() {
    0; // OK, unused expression

    ()
}
fn main() {
    { 0 }; // OK, unused expression

    ()
}
fn main() {
    { 0 } // ERROR expected (), found integer (???)

    ()
}

Apparently semicolon-less expression in the middle of a block must unify with () for some reason.

The reason is unclear to me, so this PR removes this special case and unifies StmtKind::Expr and StmtKind::Semi in HIR.
r? @nikomatsakis

[petrochenkov]

@bors try

[bors]

⌛ Trying commit bf0b6aaf8574b194bdf95fc698dd6508e02278f9 with merge af22dfc7f56a5057c6b6120a65c74e7b6c1530af...

[petrochenkov]

cc @rust-lang/lang

[Centril]

Suggested change

	/// An expression statement.
	/// An expression statement (may have any type).

[Centril]

Can you update the comment that outlines the desugaring at the top of the match arm?

[Centril]

(T-Lang: N.B. this removes the expectation that { expr } : () and so therefore:

{ core::default::Default::default() }
1;

may stop compiling (crater will find out).

We could add inference defaulting to () if that is desirable.

[cramertj]

Apparently semicolon-less expression in the middle of a block must unify with () for some reason.

Huh, that's the behavior I would've expected-- my intuition was that intermediate statements should always be of type (), and that using ; turns a T-returning-expression into a ()-returning expression.

[eddyb]

Yeah, the intention is that ; throws away the value but otherwise every statement must evaluate to (). I suspect this PR might fail on crater due removing information from inference .

[bors]

☀️ Try build successful - checks-travis
Build commit: af22dfc7f56a5057c6b6120a65c74e7b6c1530af

[petrochenkov]

@craterbot run mode=check-only

[craterbot]

👌 Experiment pr-61753 created and queued.
🤖 Automatically detected try build af22dfc7f56a5057c6b6120a65c74e7b6c1530af
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[petrochenkov]

@cramertj @eddyb
My intuition was that

• statements don't have types or values at all
• results of expressions in trailing position are returned, so their type is restricted by the return type
• results of expressions in the middle of a block are thrown away, so their type is not restricted

[craterbot]

🚧 Experiment pr-61753 is now running on agent aws-1.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-61753 is completed!
📊 57 regressed and 0 fixed (60951 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[petrochenkov]

Hmm, all the errors are in the "does not live long enough" category, rather than regressed type inference.

This is due to changes in for loop desugaring.
Previously for loops implicitly added a semicolon to the end of their body.

for x in xs {
    doit()
}

=>

for x in xs {
    doit();
}

(No other block or loop constructions do that.)

UPDATE: It's even worse - for desugaring creates a semicolon-less statement that is in the last position, but not considered trailing - something that can never be obtained from actual source code.

I'll revert this part and you'll see what effect it has on tests.

[petrochenkov]

x no longer needs to unify with (), so it's no longer an error.

[petrochenkov]

unsafe { std::mem::uninitialized() } no longer needs to unify with (), so it cannot infer its type.

[petrochenkov]

Updated with for loop desugaring changes reverted.

[eddyb]

@petrochenkov Can you open an issue about the for inconsistency?

[petrochenkov]

@eddyb

Can you open an issue about the for inconsistency?

#61902

[cramertj]

We discussed this in the @rust-lang/lang meeting and we agreed that the current behavior is roughly as-intended (implementation inconsistencies aside), and that this change and similar ones should go through the RFC process.

[petrochenkov]

Ok, this is not something important enough to go through an RFC.
A documentation issue for this quirk - rust-lang/reference#625.

The for loop inconsistency (#61902) still needs some attention.