Let SwiftLanguageRuntime depend on a Swift language runtime being present

[adrian-prantl]

This patch moves the bulk of SwiftLanguageRuntime into a private
implementation class that is only initialized after libSwiftCore has
been loaded. This delay is necessary because SwiftLanguageRuntime
communicates with the in-process Swift language runtime via global
symbols and can't be properly initialized before the runtime was
loaded. Before the runtime was loaded all queries go to the
SwiftLanguageRuntimeStub, which prints an error message for most
queries.

In addition this patch re-enables the expression evaluator loading
libSwiftCore manually. This was previously disabled to prevent
problems with statically linked runtimes on Darwin, howver, since ABI
stabiklity statically linking the runtime is no longer an option on
Darwin.

rdar://problem/58352018
rdar://problem/58117895

[adrian-prantl]

This may look like a regression at first glance, but this avoids an extra copy of the string, since we need to pass it to a Swift API that takes a const char *.

[fredriss]

I'm not sure I follow. A few questions:

• Should SwiftLanguageRuntime::IsSwiftMangledName() take a StringRef?
• The comment in cstring_is_mangled implies that ConstString::GetStringRef() doesn't always return a null-terminated string. Is this correct?

[adrian-prantl]

SwiftLanguageRuntime::IsSwiftMangledName() calls into a Swift API that takes a const char *; so changing that to a StringRef would incur an extra copy to ensure the NUL-terminator. ConstStrings are — to my knowledge — always NUL-terminated.

[fredriss]

So I don't understand what calling AsCString() instead of GetStringRef() fixes. Given cstring_is_mangled() takes a StringRef, what this achieves is creating a temporary one which will need to strlen the passed char*. What am I missing?

[adrian-prantl]

Gotcha. I was confused.

[adrian-prantl]

My apologies for the enormous patch.

[adrian-prantl]

This patch also fixes the last test failure on the branch.

[dcci]

I need a little time to review this patch properly -- I think I'll get to it by the end of today.
I have a meta comment, so I'll drop it here before I forget. One of the main nuisances of the current model is the inability of detecting whether stdlib failed to load and expressions keep going and fail in fairly non-obvious way.

My understanding is that this is kind of the first step towards a world where if stdlib isn't found and loaded correctly, expressions just can't be run. Is this correct?

[dcci]

Can you commit the NFC/cosmetic changes first -- so we can review the meat of this PR better? Thanks!

[dcci]

I think there are lots of changes that are just cosmetics, and can be separated. Like this.

[adrian-prantl]

I need a little time to review this patch properly -- I think I'll get to it by the end of today.
I have a meta comment, so I'll drop it here before I forget. One of the main nuisances of the current model is the inability of detecting whether stdlib failed to load and expressions keep going and fail in fairly non-obvious way.

My understanding is that this is kind of the first step towards a world where if stdlib isn't found and loaded correctly, expressions just can't be run. Is this correct?

No, when the stdlib isn't loaded, after this patch, SwiftUserExpression will dlopen libSwiftCore itself.

[adrian-prantl]

Can you commit the NFC/cosmetic changes first -- so we can review the meat of this PR better? Thanks!

The bulk of the patch is moving around function bodies into different classes, so this isn't going to work quite as nicely as we'd hope.

[dcci]

I need a little time to review this patch properly -- I think I'll get to it by the end of today.
I have a meta comment, so I'll drop it here before I forget. One of the main nuisances of the current model is the inability of detecting whether stdlib failed to load and expressions keep going and fail in fairly non-obvious way.
My understanding is that this is kind of the first step towards a world where if stdlib isn't found and loaded correctly, expressions just can't be run. Is this correct?

No, when the stdlib isn't loaded, after this patch, SwiftUserExpression will dlopen libSwiftCore itself.

I guess my question is: "what happens if SwiftUserExpression fails to load libSwiftcore?

[adrian-prantl]

I guess my question is: "what happens if SwiftUserExpression fails to load libSwiftcore?

Then SwiftLanguageRuntimeImpl will not be loaded (since no libswiftCore.dylib is in the loaded images) and all queries go to the stub instead.

[adrian-prantl]

... which will log an error. Note that this is a highly unlikely scenario. You could run into it on Linux by doing expr -l Swift -- 1 on a system without Swift installed.

[dcci]

LGTM.