Instead of relying on that implicit contract, would it be possible to make that explicit? For example by marking the type as already having gone through this?

#7020 implements the fix by keeping a set of types currently being processed, is that what you mean?

I think Jonas is suggesting something like a wrapper type instead of having all these functions deal in a currency of strings. I like your point Jonas, but the way I picture it, it would be "messy".

For alternatives, I also suggested the following:

1. Having TypeSystemSwiftTypeRef::IsImportedType ignore the symbols.use-swift-typeref-typesystem setting
2. Removing symbols.use-swift-typeref-typesystem altogether, I am not aware of the who uses it, I think it was a to disable TypeSystemSwiftTypeRef during initial transition – but I don't know if it's still needed

to the latter point, the existence of this infinite recursion could indicate nobody is using this setting.

Yeah, basically what Dave is describing. The most naive implementation being something like:

struct TypeName {
  std::string mangled_typename;
  bool seen = false; 
}

and then you set seen to true after you've seen the type the first time to avoid the recursion.

@JDevlieghere if you mean changing the argument from a string to something like TypeName, I think that'd be a lot of work to support something that can be solved cleanly inside this function. We'd need to change the opaque type of TypeSystemSwiftTypeRef from a string to the new type (since the recursion path back to this function goes through TypeSystemSwiftTypeRef), and I don't think that's worth doing, especially because we have 2 solutions that are less invasive.

Having TypeSystemSwiftTypeRef::IsImportedType ignore the symbols.use-swift-typeref-typesystem setting

Personally I'm not in favor of this because the user explicitly turned on the setting (it's defaulted to off, so if they turned it on they probably have a good reason for it), and it's possible this would change the answer for some types (like the ones the compiler special cases, or types we have shims for).

Removing symbols.use-swift-typeref-typesystem altogether, I am not aware of the who uses it, I think it was a to disable TypeSystemSwiftTypeRef during initial transition – but I don't know if it's still needed

I think this has some issues too:
1 - we just don't know how many people are relying on this setting (I agree with you that's probably a very small minority, but we shouldn't break them if we don't have to).
2 - it's a useful setting for us, to validate if there's a bug in the typeref typesystem or not (I use it every so often when investigating bugs which I think might be typesystem related).

Thanks for the explanation. Sounds like something we want to keep in mind in case we need to make changes here in the future, but well beyond the scope of this patch.