Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Feb 13, 2022

Commits on Aug 29, 2021

  1. Fixes KSP-KOS#3005 - now safe to use a setsuffix of a locked thing

    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 committed Aug 29, 2021
    Configuration menu
    Copy the full SHA
    a021bc1 View commit details
    Browse the repository at this point in the history