I'm looking to add library functionality that requires Swift runtime introspection, but getting access to a particular SIL symbol produces a warning:
Symbol name 'swift_getTypeByMangledNameInContext' is reserved for the Swift runtime and cannot be directly referenced without causing unpredictable behavior; this will become an error
Compiler engineers have suggested that the runtime can be used to solve certain problems, so I'm wondering how to best work around this. I can use a C shim or dlsym to silence the warning, but what is the sanctioned way of accessing this runtime functionality? In particular I am trying to access a struct metadata field's type, and this function seems to be required to do so.
@Joe_Groff tagging you since you've been in previous conversations about this.
Although the runtime is part of the stable ABI, but the compiler expects these functions to be declared and used in specific ways. Code that redeclares the symbols often does so with parameter or return types, calling convention, LLVM effect annotations, etc., different from what the compiler expects, leading to hard-to-diagnose miscompilations, compiler crashes, or optimization regressions. That's why we put that warning in place. swift_getTypeByMangledNameInContext is relatively harmless in these respects, though, and @Douglas_Gregor recently changed how we handle @_silgen_name and @_extern declarations in SIL so that they're less likely to create type conflicts with the "official" declarations of runtime and system library symbols, so I don't think it's unreasonable to use it directly.
More generally though, if there's aBuiltin or standard library function providing access to the runtime function you want, that would be the thing to use. That still currently excludes a lot of entry points. I wonder whether, akin to how we synthesize Builtin.int_<intrinsic name> functions for every LLVM intrinsic, we could also produce a Builtin.runtime_<function name> function for every runtime entry point declared in RuntimeFunctions.def. That would give the standard library and curious third parties a means to access these functions in a way that remains synchronized with the compiler's expectations of how they should be declared.
Since I don't see which platform you're targeting, it should also be noted that we only guarantee ABI stability (runtime or calling-convention-wise) on Darwin/Apple platforms.
It's usually pretty stable on other platforms because what we can meaningfully break for other platforms without breaking ABI on Apple platforms is limited, but I'm considering a change to the runtime metadata section registration ABI on ELF/COFF platforms to help with launch times on those platforms. The actual content of the metadata won't change though.
That would be fantastic. Admittedly, I don't have an immediate use case, but I'd love to have something like this for spelunking/experimenting/understanding alone.
We do have a use-case for something like this that was laid out in this forum post — in short, we’d like to be able to use swift_reflectionMirror_whatever methods directly in order to significantly boost performance (instead of proxying through Mirror, which as we all know likes to take its time). Currently adoption of these methods is pending a benchmark run and some sort of verification that these methods are, at the bare minimum, API-stable on all platforms — if the compiler could provide us a way to access these “safely”, that’d solve our biggest problem.