Rename `String::copy_from` functions to their respective encodings (`parse_latin1`, `parse_wstring`, `parse_utf32`).
The functions are doing interpretation work, not just blind copying, so they should be renamed to reflect what they actually do.
I chose the parse_ prefix to match the existing parse_utf8 and parse_utf16:
https://github.com/godotengine/godot/blob/b9437c393871c377b5ece131afaf831e78dfb6f8/core/string/ustring.h#L527-L531
Arguably, the interfaces should be made to match and the functions exposed to public, but this would be for another PR. In this one, I'm just trying to clear up semantics a bit, which should be uncontroversial.
MSVC is failing due to the feed_effects bug again (3rd PR where this happens). To quote myself from last time:
To avoid the MSVC compiler issue (which I have previously determined to be a cache issue), I am touching feed_effects.h by inserting an explicit include to a well-known file. I think it may be caused by the only include of the file being a generated file, possibly leading to the cache resolver running into a race condition when compiling the file. I hope this change can fix the problem for good (though we won't know for sure until future PRs since touching the file already invalidates the cache, fixing the issue).
MSVC is failing due to the feed_effects bug again (3rd PR where this happens). To quote myself from last time
Is it failing locally on a clean build, or only on CI build?
MSVC is failing due to the feed_effects bug again (3rd PR where this happens). To quote myself from last time
Is it failing locally on a clean build, or only on CI build?
It's a cache problem; it's not failing for clean builds. Touching the file in any way is enough to wipe the cache and get the builds to pass. I don't know if it can fail locally as well. I've been in talks with the SCons maintainers to get it fixed, but I haven't managed to make an MRP (because I don't use MSVC).
Thanks!