On 10/04/2024 11:21 AM, Liam McGillivray wrote:
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the compiler.
So that function is being used for both, and hence uses GC (appending).
Are you sure that string appending was really the problem that caused
the "TypeInfo" build error? I forgot about this, but I had already had a
working CTFE function with string appending before adding the new one
that lead to this error. The symbols that it generates could be used in
the program compiled with `betterC`.
No, for a string it shouldn't trigger the need for TypeInfo. But that
wouldn't have worked regardless.
```
string EnumPrefixes(T)(string oldName, string prefix) {
string result = "enum " ~ oldName ~ " {\n";
static foreach(member; __traits(allMembers, T)) {
result ~= " " ~ prefix ~ member ~ " = " ~
__traits(getMember, T, member).to!int.to!string ~ ",\n";
}
return result ~ "}\n";
}
```
The purpose of this was that the enums used by the C library were too
verbose. I had changed them from things like `KeyboardKey.KEY_C` to
`Key.C`. I wanted to leave the new enums written directly in the module
since these were recommended for use, but then generate the old ones
with CTFE for backwards compatibility. The function above was used like
`mixin(EnumPrefixes!Key("KeyboardKey", "KEY_"));`, and the compiler
would allow it even when building with `betterC`.
The string mixin triggers CTFE, if ``EnumPrefixes`` wasn't templated,
that would cause codegen and hence error. If you called it in a context
that wasn't CTFE only, it would codegen even with template and would error.
For quite a long time we emitted -betterC errors during semantic, we
learned that this was all around a bad idea and moved (hopefully all but
I doubt it) into the glue code. So only if it codegens will it error.
