Add support for marking custom functions as deprecated with visual warnings

[danvervlad]

Summary

• Adds the ability to mark actions, conditions, and expressions as deprecated in extension functions
• Displays visual deprecation warnings in the Events Sheet when deprecated functions are used
• Allows extension authors to provide a deprecation message explaining what to use instead

Changes

Core/GDCore:

• Added SetDeprecationMessage and IsDeprecated methods to InstructionMetadata, ExpressionMetadata, and MultipleInstructionMetadata
• Added DeprecatedExpression error type to ExpressionParserError
• Extended InstructionValidator with ValidateParameter that returns both validity and deprecation status via new ParameterValidationResult struct
• Added deprecation fields to EventsFunction model (isDeprecated, deprecationMessage)

Events Sheet (UI):

• Displays [DEPRECATED] prefix for deprecated actions and conditions
• Shows deprecation message in tooltips
• Highlights deprecated expressions with visual styling (background highlight)
• Respects the existing showDeprecatedInstructionWarning preference flag

Extension Editor:

• Added "Deprecated" checkbox in function properties
• Added "Deprecation message" text field when function is marked deprecated

[danvervlad]

Function properties

With Deprecated = true

With Deprecated = false

With Show a warning on deprecated actions and conditions = true

In event sheet

In action/condition details

In expression details

With Show a warning on deprecated actions and conditions = false

In event sheet

In action/condition details

In expression details

[danvervlad]

In extension json, for serialization

[4ian]

Hello! Thanks for opening this PR.

The extension editor UI is still a bit rough today (the extension editor has changed a lot lately and we still try to improve it). The "Private" checkbox should have been named "Hidden": when you check it, you will see that existing usages of the function appear in yellow. So I wonder if this would have fitted your need?

More context: We try to make depreciation as transparent as possible for users. This means:

• "Deprecated" functions are never removed from reviewed extensions to ensure compatibility with old projects
• "Deprecated" functions are no longer visible to users when they add new actions, but the name of the new action is usually the same so they only notice that the list of parameter has changed

In your case, I guess you want to have the deprecation explanation shown to your users?
I will discuss this a bit more with the rest of the team.

[danvervlad]

Hello! Thanks for opening this PR.

The extension editor UI is still a bit rough today (the extension editor has changed a lot lately and we still try to improve it). The "Private" checkbox should have been named "Hidden": when you check it, you will see that existing usages of the function appear in yellow. So I wonder if this would have fitted your need?

More context: We try to make depreciation as transparent as possible for users. This means:

• "Deprecated" functions are never removed from reviewed extensions to ensure compatibility with old projects
• "Deprecated" functions are no longer visible to users when they add new actions, but the name of the new action is usually the same so they only notice that the list of parameter has changed

In your case, I guess you want to have the deprecation explanation shown to your users? I will discuss this a bit more with the rest of the team.

Hi, I know about the "Hidden" checkbox, but it's intended for use within the extension itself, isn't it?
The main idea for deprecated functions is that they should be clearly marked as such and highlighted everywhere (event sheets, detailed view) with a deprecation explanation, while being hidden from search results.

[4ian]

This will probably create a crash/memory corruption. Indeed, the JS/C++ bindings are using a [Value]:
[Value] ParameterValidationResult STATIC_ValidateParameter

This means (you can check that in glue.cpp, in the C function generated for interfacing) that the returned object is a static object in C++. There is always one living in memory, which is reused across calls. Which means:

• Multiple calls will refer to the same object (the second call "erases" the first one)
• If you delete it, you actually destroyed static memory which is basically undefined behavior I guess in C++/wasm. In short, it's a crash next time this memory is accessed.

This fix is simple: don't delete it :) This is sadly the hard to find/detect bugs with the C++/JS bindings (unclear lifetime of returned C++ objects).

[danvervlad]

Yes, you are right, removed delete call for static object

[4ian]

Do you think this note is useful? This seems like a detail for the reader of the code, this could be removed I think.

[danvervlad]

Agree, removed

[4ian]

Hi! I left a comment. My main other comment is that "[DEPRECATED]" is very "heavy" on the screen and I would rather have it as an additional preference (or we remove the existing preference and replace it by a preference which is an enum: "showDeprecatedOrHiddenWarning": "no" | "icon" | "icon-and-deprecated-warning-text").

Let me know if you can rework or introduce this preference :)

[danvervlad]

Hi @4ian, the idea sounds great! I've made appropriate changes, please take a look.