Make use of latin1 encoding explicit in gdextension_interface.cpp.

[Ivorforce]

This is a small sanity PR with no change in behavior. latin1 constructors and parsing functions are exposed with this PR (as is parse_utf32 with similar reasoning).

Some functions in the gdextension interface advertise to parse latin1, but they currently parse "whatever the String constructor uses" - which is parse_latin1. This is correct, but imprecise.

To give more context, for most String constructor callers, the current parse_latin1 is incorrect, as most use it to parse utf-8 literals¹. It would be sane to make the use of latin1 explicit, to avoid confusing it with the other cases.

I also took the opportunity to clean up the memnew calls of related functions a bit.

Footnotes

1. https://github.com/godotengine/godot/issues/100641 ↩

[Repiteo]

How am I just now realizing we've never had a parsing equivalent for ascii of all things. Yeah, there's the CharString function, but the fact we've never had a parse_ascii or static String ascii feels like a wild oversight.

[Ivorforce]

How am I just now realizing we've never had a parsing equivalent for ascii of all things. Yeah, there's the CharStringfunction, but the fact we've never had aparse_ascii or static String ascii feels like a wild oversight.

Hah, yeah that surprised me too. I have a PR open for it: #101304

[Ivorforce]

Quick fix due to build failing because of erroneous cache restores.

I have previously established that including a non-generated file explicitly solves such cache issues for good.

[dsnopek]

Thanks!

Overall, this is a great idea, however, I'm a little worried about introducing subtle behavior changes. There's two spots where I think behavior may be changing, and we should discuss if this is a change we want or not.

[dsnopek]

The changes in gdextension_interface.cpp look good to me!

[Repiteo]

Needs a rebase before this can be merged

[kiroxas]

Shouldn't it return a CharString (like the latin1 above) ? Or maybe be called parse_latin1 instead ?
Because that would mean that :

String str("Hello");
CharString s1 = str.latin1();
String s2 = String::latin1("Hello"); // This seems like a shorthand for above, but it is not, one is CharString and the other is String

Wouldn't it make more sense to have it return a CharString, and maybe have a static parse_latin1 too ?

[kiroxas]

Well I see that utf8 has the same behaviour, so at least it is consistent.

[Ivorforce]

I agree, the naming is unnecessarily confusing. I opted it to be consistent for now but agree renaming the bunch may be a good idea.

[Ivorforce]

I rebased the PR to use Span. I took the opportunity to wipe my changes from gdextension_string_name_new_with_latin1_chars, which would have been somewhat of a performance regression. I can address that separately, some time.

Other than that, it should be as before!

[Repiteo]

Thanks!