`defer` inside `do` is broken

[tobyink]

Description
do { defer { ... } } doesn't run the deferred block at the end of the do block, but at the end of the block enclosing the do block.

Steps to Reproduce
This says "second" then "first".

use v5.36;
use experimental 'defer';

do {
	defer { say "first" };
};

say "second";

Expected behavior
This says "first" then "second". (Which is expected!)

use v5.36;
use experimental 'defer';

{
	defer { say "first" };
};

say "second";

(Note that the same bug is seen in Syntax::Keyword::Defer!)

[tobyink]

Declaring a variable, any variable, inside the do block fixes it.

Also adding use strict inside the do block fixes it.

I guess the do is being optimized away (even though it's still visible in B::Deparse output) but either of the above things prevent it from being optimized away. The presence of a defer block should also prevent it from being optimized away.

[tobyink]

Here's an even more minimal case.

use v5.36;
use experimental 'defer';

do {
	#();
	defer { say "first" };
};

say "second";

The output changes depending on whether (); is commented or not!

[iabyn]

On Mon, Nov 07, 2022 at 07:18:24AM -0800, Toby Inkster wrote: Here's an even more minimal case.

It's a more general problem with do {} blocks. If the block only contains a single expression, it isn't treated as a scope; Turn it into multiple statements and it does. The defer issue is just a symptom of that. This: sub DESTROY { print "DESTROY\n" } do { my $x = bless []; }; print "left DO\n"; outputs left DO DESTROY but add a second statement: sub DESTROY { print "DESTROY\n" } do { my $x = bless []; my $y; }; print "left DO\n"; and the destructor is called on scope exit: DESTROY left DO

…

-- Overhead, without any fuss, the stars were going out. -- Arthur C Clarke