Demangle an OpaqueArchetypeTypeRef's ID as a type not as a symbol

[augusto2112]

rdar://102064732

[augusto2112]

@swift-ci smoke test

[slavapestov]

Can you add a test case?

[augusto2112]

@swift-ci smoke test

[augusto2112]

@slavapestov, I talked with @jckarter and currently this doesn't seem to be easy to test from the swift repo, we'd need a an offline tool that uses remote mirror to reproduce this case. I will add a test in LLDB that exercises this specific demangling operation, hopefully that should be enough?

[slavapestov]

@augusto2112 What does the test case look like? You should be able to test most TypeDecoder code paths via lldb-moduleimport-test from test/TypeDecoder, or swift-reflection-dump from test/Reflection.

[augusto2112]

@slavapestov sorry, had to work on other issues.

This is the lldb test case:

protocol P {}

struct S: P {}

struct A<T> {
  let t: T
}
let p: some P = S()
let a = A(t: p)
print(1) // Stop here, run "v a"

I could not figure out a way to test this purely from the compiler side.

[augusto2112]

@swift-ci smoke test

[kastiglione]

So I just debugged this for other crashes, and came up with the exact same diff. I asked @jckarter about the change, and he pointed me here.

Given:

• this is the cause of lldb crashes which is frustrating users
• is not being debated as incorrect
• had no tests when initially implemented

I think it's best to merge this and follow up with tests later. I am happy to take that on, @augusto2112.

[kastiglione]

@swift-ci test Windows Platform

[augusto2112]

LLDB test: swiftlang/llvm-project#5848

[adrian-prantl]

Let's merge this now since it's tested in LLDB. We can still follow up later with a test inside of the swift repo if we find a way to do this.