Soft-deprecate the use of implicit reliance on NULL-terminated strings.

[Ivorforce]

"MVP" of addressing godotengine/godot-proposals#11249. The motivation for this direction are discussed there (and linked issues). This PR does not yet change assumptions about user-supplied strings; NULL termination checks are only avoided for static strings supplied from the codebase.

This change is toggled with the c++-define GODOT_SHOW_STR_DEPRECATIONS (off by default). For unowned string references, StrRange can be used, which avoids allocation overhead. This is already employed in sprintf and operator+ in this PR, because there are a lot of uses of these functions.

This change is as minimal as I could realistically get it to be: ustring has quite a lot of changes, but most other files work exactly as before. This changes when GODOT_SHOW_STR_DEPRECATIONS is toggled: Suddenly, the console explodes into a flurry of warnings, because strlen is used in a place where it may be inappropriate and wastes CPU cycles.

This PR should already slightly improves performance by letting callers pass their string[] as string[] with known lengths, rather than having it recomputed immediately. Every change we will make to get rid of another GODOT_SHOW_STR_DEPRECATIONS deprecation warning will improve the engine speed further. Every function we can make refactor to use StrRange instead of String will reduce allocations and improve engine speed.

Please, participate in lively discussion! I realize merging this is kind of a large ask, especially from a pretty fresh contributor like myself. I tried to make the change as unopinionated as possible, and focused on just improving speed and conditions for future PRs to improve speed further.

Still, I personally think this direction is unavoidable sooner or later, if we want to make the best use of clock cycles for the hard parts elsewhere. Also, i have heard it mentioned a few times that the Godot source code has a side-mission as a learning tool - making computation explicit to avoid accidental promotions and data copies is very important in clean and fast code :)

[Mickeon]

This feels somewhat related to #84680 @Repiteo

[clayjohn]

Sounds interesting! Can you share the results of your profiling so we have an idea of what kind of performance differential to expect?

[Ivorforce]

Sounds interesting! Can you share the results of your profiling so we have an idea of what kind of performance differential to expect?

Will do once I get everything rolling again! It's still stuck between not compiling or causing segfaults, hopefully to resolve soon :)

[clayjohn]

Will do once I get everything rolling again! It's still stuck between not compiling or causing segfaults, hopefully to resolve soon :)

In that case, I've marked this as draft so maintainers aren't poked every time this is updated. Please mark it as ready for review once it's functioning and you are ready for a review

[Ivorforce]

I'm putting implementation of this PR on ice.

It was looking very promising, but at the very end implicit conversions to String and StringName prevented the completion of the feature. I've opened godotengine/godot-proposals#11257 and godotengine/godot-proposals#11258 to address the specific issues I was running into.

When some preliminary work has been done, i hope to be able to continue work on this PR.

[adamscott]

Hello @Ivorforce ! I hope you're doing well.

The release team found out that you were updating your PR a lot lately. Could you add a tag in your commit message when CI checks are not needed? (see https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs)

It's because each time you push an update, even a tiny one, it triggers full CI checks. 😅

[Ivorforce]

Yep, sorry, will do!