Skip to content

Fixes #3005 - now safe to use a setsuffix of a locked thing#3010

Merged
Dunbaratu merged 1 commit intoKSP-KOS:developfrom
Dunbaratu:fixes_3005_set_suffix_of_locks
Feb 13, 2022
Merged

Fixes #3005 - now safe to use a setsuffix of a locked thing#3010
Dunbaratu merged 1 commit intoKSP-KOS:developfrom
Dunbaratu:fixes_3005_set_suffix_of_locks

Conversation

@Dunbaratu
Copy link
Member

Fixes #3005 - The discussion of the problem is long, see the issue #3005.

There was logic in the compiler that handled this situation:

When in the context of compiling the lefthand side of a SET assignment,
if that lefthand side is a function name, it should suppress the "invoke
even when no parentheses are present" logic, like so:

  set x to { return 1. }. // x is now a delegate function.
  print x. // Should call x() the function, even with the () missing.
  set x to 3. // Should NOT call x() when replacing x with a 3.

The problem was that this same logic that tries to handle that was
partly firing off when the 'x' in question was followed by a suffix,
when that should not be happening in that case:

  set x to { return ship. }.
  set x:name to "hello". // Here x() DOES need to be called, to return
                         // SHIP, which then gets its suffix :name set.

It was partially skipping half the work of setting up for the function
call because it failed to realize one was coming. The part it skipped
was the part that inserts the KOSArgMarker on the stack before the call
happens.

Fixes KSP-KOS#3005 - The discussion of the problem is long, see the issue KSP-KOS#3005.

There was logic in the compiler that handled this situation:

When in the context of compiling the lefthand side of a SET assignment,
if that lefthand side is a function name, it should suppress the "invoke
even when no parentheses are present" logic, like so:

```
  set x to { return 1. }. // x is now a delegate function.
  print x. // Should call x() the function, even with the () missing.
  set x to 3. // Should NOT call x() when replacing x with a 3.
```
The problem was that this same logic that tries to handle that was
partly firing off when the 'x' in question was followed by a suffix,
when that should not be happening in that case:
```
  set x to { return ship. }.
  set x:name to "hello". // Here x() DOES need to be called, to return
                         // SHIP, which then gets its suffix :name set.

```
It was partially skipping half the work of setting up for the function
call because it failed to realize one was coming.  The part it skipped
was the part that inserts the KOSArgMarker on the stack before the call
happens.
@Dunbaratu Dunbaratu added the bug Weird outcome is probably not what the mod programmer expected. label Aug 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Weird outcome is probably not what the mod programmer expected.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Setting suffix of a lock misaligns stack. was: "incorrect error responce in terminal"

2 participants