Sequence points for some of RET statements are improperly generated #1393

New issue

Open

opened 2025-12-28 17:16:17 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:16:17 +00:00

Owner

Originally created by @AnnaShaleva on GitHub (Oct 17, 2024).

Current Behavior

For some RET instructions our compiler generates sequence points with improper boundaries, for example for void functions (if there's no explicit return keyword in the code), also for functions with named parameters where explicit return keyword is missing and may be for more cases that I'm not aware of (it needs to be investigated). The example of such function is given here: https://github.com/nspcc-dev/neo-go/issues/3559#issuecomment-2414148935.

Improper boundaries of such sequence points include the whole function body, like it's described here: https://github.com/nspcc-dev/neo-go/pull/3617#issue-2592286954

One case is caused by this code (but there are probably more cases):
nspcc-dev/neo-go@86ed214e8a/pkg/compiler/codegen.go (L542-L543)

This behaviour is invalid, because:

There are some return statements that have proper boundaries of sequence points. For example, non-void functions where return keyword is explicitly present. It's because return keyword is properly handled by our compiler and sequence point is generated only for the return AST node:
nspcc-dev/neo-go@14ea5a8d32/pkg/compiler/codegen.go (L755)
nspcc-dev/neo-go@14ea5a8d32/pkg/compiler/codegen.go (L793)
C# compiler properly handles the described case and generates RET sequence points with short-range. Although it has slightly different behaviour in that it bounds RET opcodes to closing brackets of the corresponding functions (}). This behaviour is described here: https://github.com/nspcc-dev/neo-go/pull/3617#issuecomment-2419970469

Expected Behavior

Boundaries of all sequence points corresponding to RET opcodes must not have function-wide bounds.

Possible Solution

Rework the way how sequence points generated for RET opcodes. At least fix these "function-wide" sequence points. May be rework the whole scheme of RET sequence points generation to make the behaviour similar to C# compiler.

Additional context

Related to #3559 and #3617.

Originally created by @AnnaShaleva on GitHub (Oct 17, 2024). ## Current Behavior For some RET instructions our compiler generates sequence points with improper boundaries, for example for void functions (if there's no explicit `return` keyword in the code), also for functions with named parameters where explicit `return` keyword is missing and may be for more cases that I'm not aware of (it needs to be investigated). The example of such function is given here: https://github.com/nspcc-dev/neo-go/issues/3559#issuecomment-2414148935. Improper boundaries of such sequence points include the whole function body, like it's described here: https://github.com/nspcc-dev/neo-go/pull/3617#issue-2592286954 One case is caused by this code (but there are probably more cases): https://github.com/nspcc-dev/neo-go/blob/86ed214e8a53859fd85482370be20eb613c61419/pkg/compiler/codegen.go#L542-L543 This behaviour is invalid, because: 1. There are some `return` statements that have proper boundaries of sequence points. For example, non-void functions where `return` keyword is explicitly present. It's because `return` keyword is properly handled by our compiler and sequence point is generated only for the `return` AST node: https://github.com/nspcc-dev/neo-go/blob/14ea5a8d3271df25394c6fc5aac84f1bf8398264/pkg/compiler/codegen.go#L755 https://github.com/nspcc-dev/neo-go/blob/14ea5a8d3271df25394c6fc5aac84f1bf8398264/pkg/compiler/codegen.go#L793 2. C# compiler properly handles the described case and generates `RET` sequence points with short-range. Although it has slightly different behaviour in that it bounds `RET` opcodes to closing brackets of the corresponding functions (`}`). This behaviour is described here: https://github.com/nspcc-dev/neo-go/pull/3617#issuecomment-2419970469 ## Expected Behavior Boundaries of all sequence points corresponding to `RET` opcodes must not have function-wide bounds. ## Possible Solution Rework the way how sequence points generated for `RET` opcodes. At least fix these "function-wide" sequence points. May be rework the whole scheme of `RET` sequence points generation to make the behaviour similar to C# compiler. ## Additional context Related to #3559 and #3617.