In https://reviews.llvm.org/D122373 I changed how the apple simulator platform plugins would find the SDK path given the name of an SDK -- so we would wait until we were actually Creating the plugin to call xcrun to find the full path. If a system doesn't have a given SDK installed, this xcrun call can be very slow, so delaying that search until we know we need a specific simulator platform to be selected, avoided that problem.
I have a new way of hitting this now, and need to make it even more lazy. qProcessInfo can give lldb a list of addresses of binaries to load -- and in the case of the kernel, the address is the address of a *kernelset*. We need some Mach-O fileset specific code to find the kernel in the fileset. So ProcessGDBRemote force-creates every platform, and asks it, "can you do something with this address that might be a fileset". PlatformDarwinKernel knows how to do something. But every platform is force-Created, so if the create is expensive (as it is with the simulator platforms), we have a big delay if some SDKs aren't installed on the system.
This patch moves the expansion of (primary sdk name, seconary sdk name) -> sdk filepath until it's actually used by the simulator platform methods -- much later than the CreateInstance, when the platform is actually being used. It will only be calculated once.
I'd call it a NFC change tbh, but it does avoid a very expensive external cost so it's not completely accurate. It's a big important for this use case.
Use std::move to avoid a needles copy.