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

petrochenkov · 2019-06-11T21:59:27Z

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 · 2019-06-11T21:59:59Z

@bors try

bors · 2019-06-11T22:00:17Z

⌛ Trying commit bf0b6aaf8574b194bdf95fc698dd6508e02278f9 with merge af22dfc7f56a5057c6b6120a65c74e7b6c1530af...

petrochenkov · 2019-06-11T22:00:47Z

cc @rust-lang/lang

Centril · 2019-06-11T22:05:00Z

src/librustc/hir/mod.rs

@@ -1205,20 +1205,16 @@ pub enum StmtKind {
    /// An item binding.
    Item(ItemId),

-    /// An expression without a trailing semi-colon (must have unit type).
+    /// An expression statement.


Suggested change

/// An expression statement.

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

Centril · 2019-06-11T22:09:09Z

src/librustc/hir/lowering.rs

-                    hir_vec![next_let, match_stmt, pat_let, body_stmt],
-                    None,
+                    hir_vec![next_let, match_stmt, pat_let],
+                    Some(body_expr),


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

Centril · 2019-06-11T22:11:55Z

src/librustc_typeck/check/mod.rs

@@ -4856,10 +4856,6 @@ impl<'a, 'gcx, 'tcx> FnCtxt<'a, 'gcx, 'tcx> {
            // Ignore for now.
            hir::StmtKind::Item(_) => {}
            hir::StmtKind::Expr(ref expr) => {
-                // Check with expected type of `()`.
-                self.check_expr_has_type_or_error(&expr, self.tcx.mk_unit());


(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 · 2019-06-11T22:36:12Z

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 · 2019-06-11T22:50:23Z

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 · 2019-06-12T00:35:07Z

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

petrochenkov · 2019-06-12T08:33:16Z

@craterbot run mode=check-only

craterbot · 2019-06-12T08:33:18Z

👌 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 · 2019-06-12T09:11:22Z

@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 · 2019-06-12T12:54:28Z

🚧 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 · 2019-06-14T23:05:57Z

🎉 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 · 2019-06-15T08:10:55Z

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.

…wering to HIR

petrochenkov · 2019-06-16T09:20:37Z

src/test/ui/mismatched_types/for-loop-has-unit-body.rs

 fn main() {
    for x in 0..3 {
-        x //~ ERROR mismatched types
+        x


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

petrochenkov · 2019-06-16T09:21:05Z

src/test/ui/for/for-loop-has-unit-body.rs

 fn main() {
    // Check that the tail statement in the body unifies with something
    for _ in 0..3 {
-        unsafe { std::mem::uninitialized() }
+        unsafe { std::mem::uninitialized() } //~ ERROR type annotations needed


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

petrochenkov · 2019-06-16T09:21:36Z

Updated with for loop desugaring changes reverted.

eddyb · 2019-06-16T11:43:35Z

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

petrochenkov · 2019-06-16T20:41:04Z

@eddyb

Can you open an issue about the for inconsistency?

#61902

cramertj · 2019-06-20T19:23:23Z

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 · 2019-06-20T21:06:08Z

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.

rust-highfive assigned nikomatsakis Jun 11, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 11, 2019

petrochenkov added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jun 11, 2019

petrochenkov added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 11, 2019

Centril reviewed Jun 11, 2019

View reviewed changes

Centril added I-nominated needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels Jun 11, 2019

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jun 14, 2019

petrochenkov added 2 commits June 16, 2019 11:38

Do not discern between statements with and without semicolon after lo…

dd884e0

…wering to HIR

Revert changes in for loop desugaring

0e716aa

petrochenkov force-pushed the noexpr branch from bf0b6aa to 0e716aa Compare June 16, 2019 09:10

petrochenkov commented Jun 16, 2019

View reviewed changes

petrochenkov mentioned this pull request Jun 16, 2019

for loop desugaring treats the loop's trailing expression in unusual way #61902

Open

petrochenkov mentioned this pull request Jun 20, 2019

Document that expressions in non-trailing expression statements without semicolon must have type () rust-lang/reference#625

Open

petrochenkov closed this Jun 20, 2019

petrochenkov deleted the noexpr branch July 1, 2019 22:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

petrochenkov commented Jun 11, 2019 •

edited

Loading

petrochenkov commented Jun 11, 2019

bors commented Jun 11, 2019

petrochenkov commented Jun 11, 2019

Centril Jun 11, 2019

Centril Jun 11, 2019

Centril Jun 11, 2019

cramertj commented Jun 11, 2019

eddyb commented Jun 11, 2019

bors commented Jun 12, 2019

petrochenkov commented Jun 12, 2019

craterbot commented Jun 12, 2019

petrochenkov commented Jun 12, 2019

craterbot commented Jun 12, 2019

craterbot commented Jun 14, 2019

petrochenkov commented Jun 15, 2019 •

edited

Loading

petrochenkov Jun 16, 2019

petrochenkov Jun 16, 2019

petrochenkov commented Jun 16, 2019

eddyb commented Jun 16, 2019

petrochenkov commented Jun 16, 2019

cramertj commented Jun 20, 2019

petrochenkov commented Jun 20, 2019

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

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

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

Conversation

petrochenkov commented Jun 11, 2019 • edited Loading

petrochenkov commented Jun 11, 2019

bors commented Jun 11, 2019

petrochenkov commented Jun 11, 2019

Centril Jun 11, 2019

Choose a reason for hiding this comment

Centril Jun 11, 2019

Choose a reason for hiding this comment

Centril Jun 11, 2019

Choose a reason for hiding this comment

cramertj commented Jun 11, 2019

eddyb commented Jun 11, 2019

bors commented Jun 12, 2019

petrochenkov commented Jun 12, 2019

craterbot commented Jun 12, 2019

petrochenkov commented Jun 12, 2019

craterbot commented Jun 12, 2019

craterbot commented Jun 14, 2019

petrochenkov commented Jun 15, 2019 • edited Loading

petrochenkov Jun 16, 2019

Choose a reason for hiding this comment

petrochenkov Jun 16, 2019

Choose a reason for hiding this comment

petrochenkov commented Jun 16, 2019

eddyb commented Jun 16, 2019

petrochenkov commented Jun 16, 2019

cramertj commented Jun 20, 2019

petrochenkov commented Jun 20, 2019

petrochenkov commented Jun 11, 2019 •

edited

Loading

petrochenkov commented Jun 15, 2019 •

edited

Loading