[lldb] Restore upstream implementation of ClangPersistentVariables::RemovePersistentVariable

[kastiglione]

Change ClangPersistentVariables::RemovePersistentVariable to use the implementation of upstream lldb.

For reasons unknown to me, this version of ClangPersistentVariables has been supporting Swift-specific persistent variable names, such as $R1 or $E1. As far as I know, this support isn't needed on the Clang side. Such variables are already supported on the Swift side, see SwiftPersistentExpressionState.

rdar://115829246

[kastiglione]

@swift-ci test

[kastiglione]

@swift-ci test

[kastiglione]

@jimingham any reason why this clang specific version would end up with Swift support in it, and diverge from upstream? Was it unintentional, or intentional for an as yet unknown reason to me?

[kastiglione]

@swift-ci test macOS

[jimingham]

I don't remember why this code is where it is.
For this to be relevant, a clang expression would have to be able to produce a swift object. If you call a swift function that is bridged to ObjC is there a chance that could return a swift result or error which, since we see dynamically is a Swift language runtime object we would give the swift result/error name to? I'm not up on how the Swift->ObjC interop works these days...

[kastiglione]

Note that m_next_persistent_error_id is never incremented, which leads me to think that the answer to your question is no. I will check on whether there's a way for a bridged objc function to be bridged as throws.

[kastiglione]

@swift-ci test

[kastiglione]

If you call a swift function that is bridged to ObjC is there a chance that could return a swift result or error which, since we see dynamically is a Swift language runtime object we would give the swift result/error name to?

I was unable to make this happen.

[kastiglione]

@swift-ci test windows

[kastiglione]

@adrian-prantl would you mind merging this?