Bump the toolchain group with 2 updates

[dependabot]

Bumps the toolchain group with 2 updates: @abaplint/cli and @abap2ui5/render-runtime.

Updates @abaplint/cli from 2.119.66 to 2.120.24

Commits

• 750d354 chore(release): v2.120.24 (#4216)
• 7a6c96c bugfix RAP events syntax (#4215)
• 7941fe5 chore(release): v2.120.23 (#4214)
• 8f17f8e bugfix syntax (#4211)
• bf57901 chore(release): v2.120.22 (#4210)
• 7e14753 bugfix CREATE OBJECT (#4209)
• 3aa3498 chore(release): v2.120.21 (#4208)
• 81cfaf7 bugfix PRIVILEGED (#4207)
• b583183 Report event name conflicts with other class components (#4206)
• be4ec1f Add built-in function diagrams to syntax page (#4204)
• Additional commits viewable in compare view

Updates @abap2ui5/render-runtime from 0.1.1 to 0.2.1

Release notes

Sourced from @​abap2ui5/render-runtime's releases.

v0.2.1

The theme of this release is the lifecycle rules seeing the code that is there. 0.2.0 was about findings that were not true; these three are about code the rules could not read at all — a handle with another name, a branch that does not exist, and an expression mistaken for a statement.

• COND's ELSE is not the IF's ELSE. ifBranchEnd scanned for the WORD ELSE to find where a lifecycle branch stops, and

  status = COND #( WHEN i MOD 2 = 0 THEN `open` ELSE `closed` ).
  

  puts one at IF-depth 0, so the branch ended there — four statements before the view_display( ) it actually contains, which was then reported as a branch that never re-displays. Found on a real documentation page, not by reading. A false positive on idiomatic modern ABAP is the worst kind: it costs more than a suppression, it pushes people away from COND to satisfy a rule about something else. The scanner tracks parenthesis depth now, so inside an unclosed ( nothing is a statement keyword. Two tests, both directions — the second (a COND must not HIDE a branch that genuinely never displays) is the one that matters, because a fix that blinds the scanner passes the first alone.

• The lifecycle rules find a client handle that is not called client. missing-on-navigated-branch, missing-view-display-on-navigated and separate-lifecycle-ifs all matched the receiver literally as client->. A class that names the handle differently was not judged leniently, it was invisible: abap2UI5/samples-stack's app 319 calls it m_client, has no check_on_navigated( ) branch, and no rule said a word. mo_client and me->client are in the corpora too. The handle is matched by shape now, and three assertions pin it.

• New rule missing-on-navigated-branch (warning). The complement of missing-view-display-on-navigated, which has always judged a check_on_navigated( ) branch that never re-displays. The far more common shape in the wild has no branch at all, and nothing could see it.

  check_on_init( ) means "this app INSTANCE never ran", not "the app starts" — abap2UI5 flips mv_check_initialized in db_save( ) after the very first roundtrip. It is therefore false on three roundtrips that put the app back on screen: a called app leaving through nav_app_leave( ), one of the built-in z2ui5_cl_pop_* value helps returning (those run over nav_app_call too), and a bookmarked draft being restored. All three raise check_on_navigated( ) alone; with no branch for it main( ) does nothing, the response carries no display, and the model is pushed into a MAIN slot still holding the other app's view. The screen stays wrong with no error anywhere — which is why an app written this way works perfectly until the day something navigates into it, and why the defect is usually reported as "it broke when I put it behind a navigation" long after the app was written.

... (truncated)

Changelog

Sourced from @​abap2ui5/render-runtime's changelog.

0.2.1

The theme of this release is the lifecycle rules seeing the code that is there. 0.2.0 was about findings that were not true; these three are about code the rules could not read at all — a handle with another name, a branch that does not exist, and an expression mistaken for a statement.

• COND's ELSE is not the IF's ELSE. ifBranchEnd scanned for the WORD ELSE to find where a lifecycle branch stops, and

  status = COND #( WHEN i MOD 2 = 0 THEN `open` ELSE `closed` ).
  

  puts one at IF-depth 0, so the branch ended there — four statements before the view_display( ) it actually contains, which was then reported as a branch that never re-displays. Found on a real documentation page, not by reading. A false positive on idiomatic modern ABAP is the worst kind: it costs more than a suppression, it pushes people away from COND to satisfy a rule about something else. The scanner tracks parenthesis depth now, so inside an unclosed ( nothing is a statement keyword. Two tests, both directions — the second (a COND must not HIDE a branch that genuinely never displays) is the one that matters, because a fix that blinds the scanner passes the first alone.

• The lifecycle rules find a client handle that is not called client. missing-on-navigated-branch, missing-view-display-on-navigated and separate-lifecycle-ifs all matched the receiver literally as client->. A class that names the handle differently was not judged leniently, it was invisible: abap2UI5/samples-stack's app 319 calls it m_client, has no check_on_navigated( ) branch, and no rule said a word. mo_client and me->client are in the corpora too. The handle is matched by shape now, and three assertions pin it.

• New rule missing-on-navigated-branch (warning). The complement of missing-view-display-on-navigated, which has always judged a check_on_navigated( ) branch that never re-displays. The far more common shape in the wild has no branch at all, and nothing could see it.

  check_on_init( ) means "this app INSTANCE never ran", not "the app starts" — abap2UI5 flips mv_check_initialized in db_save( ) after the very first roundtrip. It is therefore false on three roundtrips that put the app back on screen: a called app leaving through nav_app_leave( ), one of the built-in z2ui5_cl_pop_* value helps returning (those run over nav_app_call too), and a bookmarked draft being restored. All three raise check_on_navigated( ) alone; with no branch for it main( ) does nothing, the response carries no display, and the model is pushed into a MAIN slot still holding the other app's view. The screen stays wrong with no error anywhere — which is why an app written this way works perfectly until the day something navigates into it, and why the defect is usually reported as "it broke when I put it behind a navigation" long after the app was written.

... (truncated)

Commits

• 599cecc release v0.2.1 (#48)
• f829c9d release v0.2.0
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions