`console.log` inside `if/else` branches is skipped by debugger session

[michaelsutton]

console.log(...) generally works in the debugger, including:

• updated locals
• struct/object values
• values mutated inside a branch and logged afterward

What does not work is a console.log(...) located inside the branch body itself.

Minimal shape:

int sum = a + b;
console.log("start", sum);
if (sum > 5) {
    sum = sum + 10;
    console.log("then", sum);
} else {
    sum = sum - 1;
    console.log("else", sum);
}
console.log("after", sum);

Expected:

• with (2, 5): start 7, then 17, after 17
• with (2, 3): start 5, else 4, after 4

Actual debugger output:

• with (2, 5): start 7, after 17
• with (2, 3): start 5, after 4

So branch-local console logs are skipped, but branch-updated values are still propagated correctly.

Basic debugger-session steps used in the regression tests:

1. compile contract with record_debug_infos: true
2. create session with DebugSession::full(...)
3. execute with stepping / opcode stepping
4. collect emitted console output with take_console_output()

Relevant local tests on my branch:

• passing: debug_session_console_logs_reflect_updated_variable_values
• passing: debug_session_console_logs_reflect_branch_updated_values_after_if_else
• failing/ignored: debug_session_console_logs_reflect_updated_values_inside_if_else

Repo / branch:
https://github.com/michaelsutton/silverscript/tree/console-log-regression

Direct link to the ignored failing regression:
https://github.com/michaelsutton/silverscript/blob/console-log-regression/debugger/session/tests/debug_session_tests.rs#L210

This looks like a debugger step/console emission issue for branch-local zero-width console steps, not a value propagation problem.

[michaelsutton]

follow-up questions/comments:

@someone235 is it known/intentional that console.log(...) can still affect compiler decisions and therefore exact codegen / size, even though the statement itself lowers to no bytecode? I noticed that adding a debug console.log(...) line in a chess contract changed the final probe numbers, which seems to come from its arguments participating in identifier-use / binding analysis.

Also, while probing a real covenant flow, I saw one small rendering quirk: a value that is logically 0 can show up in console output as []. If the static type at that site is known to be int, it seems like the logger / formatter should probably interpret [] as 0 rather than rendering the empty stack item literally.

[Manyfestation]

follow-up questions/comments:

@someone235 is it known/intentional that console.log(...) can still affect compiler decisions and therefore exact codegen / size, even though the statement itself lowers to no bytecode? I noticed that adding a debug console.log(...) line in a chess contract changed the final probe numbers, which seems to come from its arguments participating in identifier-use / binding analysis.

Also, while probing a real covenant flow, I saw one small rendering quirk: a value that is logically 0 can show up in console output as []. If the static type at that site is known to be int, it seems like the logger / formatter should probably interpret [] as 0 rather than rendering the empty stack item literally.

I don't yet understand all the quirks of the compiler, but it seems problematic that console.log has any side effect.

Regarding the rendering thing- the debugger infer the data type and when 0 elemnts/values given to an array, it would show as [] - debugger/session/src/presentation.rs module -

            format!("[{}]", values.join(", "))

We can change that if you have better suggestion.

[michaelsutton]

it would show as [] - debugger/session/src/presentation.rs module -

the script engine uses minimal encoding when it can, so 0 can be represented as no bytes. so if you know the type is int, you should/can safely map [] -> 0

[Manyfestation]

it would show as [] - debugger/session/src/presentation.rs module -

the script engine uses minimal encoding when it can, so 0 can be represented as no bytes. so if you know the type is int, you should/can safely map [] -> 0

If you see [] it means the debugger inferred an array type, this might be a bug in the inferring type logic then.