default cases have nothing special, they should be handled exactly like case:

This should evaluate to 1:

const a = do {
  switch (2) {
    default: 0;
    case 1: 1; break;
  }
};

This should evaluate to 1:

const a = do {
  switch (1) {
    case 1: 1;
  }
};

The check should probably be more like if (isLastStatement) {

Also this should evaluate to 1:

const a = do {
  switch (1) {
    case 1: 1;
    case 2:
  }
};

So can I say that the lastStatement is an expression statement , then no fall through, else will fall through say:

let a = 1
const b = do {
switch (1) {
   case 1: a = 2;
   case 2: a * 10;
}

So b = ?

10, because the last statement is a*10

ok. interesting. is this documented somewhere within https://github.com/tc39/proposal-do-expressions? or where do I find the spec for this?

1. Switch expressions evaluate to the result of their block: https://tc39.es/ecma262/#sec-switch-statement-runtime-semantics-evaluation steps 7 and 9
2. It delegates to https://tc39.es/ecma262/#sec-runtime-semantics-caseblockevaluation, in the CaseBlock: { CaseClauses } section.
   i. At the first iteration of step 4 of that algorithm, V is set to 2 (the result of a = 2).
   ii. Since case 1 isn't followed by a break/return/throw statement, R is a NormalCompletion and not an AbruptCompletion: for this reason the loop continues running to the following case.
   iii. At the second iteration, V is set to 20 (the result of a * 10).
   iv. The loop ends, because there are no more cases, and it returns 20

🤦‍♂️ 🤦‍♂️ 🤦‍♂️ 🤦‍♂️
I just noticed I wrote 10 instead of 20

I realised reading the ECMA262 Spec is giving me more confusion 🤦‍♂ 🤦‍♂ 🤦‍♂, but I guess I roughly know what you trying to point out. And I think we should document more in the do-expression proposal docs

Btw, you can already "test" do expression in any browser.

do { ANYTHING }

is

eval(`{
  ANYTHING
}`);

@nicolo-ribaudo i need some help over here, i've figured this as a plausible test case, but I not sure how i should transform this.

Previously, what I did is to find the BreakStatement, and turn the statement before BreakStatement as a completionPath, which would then be transformed into a return statement.

Problem I've created right now is that the previous statement could be anything from BlockStatement to nested BlockStatements, and I need to find the "last statement" which I am kind stuck on how I should go for this...
not entirely sure I am in the right direction, that's why I am seeking some help over here

I'm not sure about how to solve it, but it isn't a problem just for switchs. It's a problem for everything which uses break.

e.g.

let a = do {
  while (1) {
    1;
    break;
    2;
  }
};

I think that we should try to fix it separately since it is a really hard problem and this PR is already a big improvement.

OK I guess I shall disable that test case then

I suggest check isLastCaseWithConsequent early so that it may skip the whole hasConsequent setup when it is false.

@JLHwung updated!

nit: I think it should be breakStatement.scope.buildUndefinedNode().

@JLHwung sure!

After #10243 they will be logically equivalent: buildUndefinedNode does not depend on scope any more. It is by reviewing this PR that I find the room for improvements in buildUndefinedNode.