Update: This bug seems to be triggered (unreliably) by any sort of syntax/semantic error involved with the attribute parameter. Leaving the field blank, e.g. {reason=} will also trigger the crash, and attempting to use variables (whether defined or not) will also crash, discovered by @neilex_is.
In release 687, which enables the @deprecated function attribute with optional parameters, passing a number value to one of the parameters causes the linter (and studio) to crash.
Typing the following repro into a script container with typechecking enabled will crash studio.
@[deprecated{reason=123}] local function foo() end
Note that using the --!nocheck flag does NOT prevent this issue.
This bug will softlock you out of your place if the script saves the problematic snippet before you crashed, since the linter will automatically run every time you open your place with the script container open (which is also automatic). Closing the script container right before it crashes can prevent another crash the next time you open your place, and the softlock can be fixed by manually editing the .Source of your script to remove the attribute flag.
The only solution I’m able to think of is to quickly close the script container with the bug (since the linting happens if the script container is open), reopen the place, and then manually edit the script’s .Source property to remove the problematic snippet.
Thank you for the report! We’re rolling back the flag enabling @deprecated for now in Studio since the underlying cause means that it would currently be impossible to actually type the attribute out as many of you are noting. We’ve left it on in RCC for anyone who managed to deploy an experience with the attribute anyhow because the issue is specific to the analysis part of the implementation. The engineer who implemented it will look into fixing this ASAP.