Reland "[cxx-interop] Allow import-as-member for types in namespaces"

[egorzhdan]

This brings back e95f6a3 after it got reverted in dd809c6.

Please see the original PR for motivation: #82496.

This fixes the following issue with the original PR:

AppKit renames some of its C constants via API Notes, e.g. NSUpArrowFunctionKey is renamed into NSEvent.SpecialKey.upArrow.rawValue.

In this example, NSEvent is an existing type, but SpecialKey is not, so the Swift compiler synthesizes an empty type named SpecialKey.

The logic that was added to support import-as-member for namespaces did not account for this: it assumed that if a nested type wasn't found, then the name must be invalid.

rdar://154783494

[egorzhdan]

@swift-ci please test

swiftlang/llvm-project#11051

[egorzhdan]

@swift-ci please test

swiftlang/llvm-project#11051

[egorzhdan]

swiftlang/llvm-project#11051

@swift-ci please test

[egorzhdan]

swiftlang/llvm-project#11051

@swift-ci please test

[j-hui]

The logic that was added to support import-as-member for namespaces did not account for this: it assumed that if a nested type wasn't found, then the name must be invalid.

I'm a little bit confused by this. Was this logic on the Swift side or the Clang side? And what was changed between the original patches and these re-landed patches?

The only difference I see with respect to the original patch is this, on the Swift side:

  if (!parentContext)
     return nullptr;

And the Clang side re-land looks identical to before. But I thought the problem would stem from the Clang side, since the issue required us to revert the Clang side as well. Or did I miss a Clang-side difference?

[egorzhdan]

swiftlang/llvm-project#11051

@swift-ci please test

[egorzhdan]

@j-hui good question, the split between a Clang-side change and a Swift-side change is indeed confusing here.

The problematic part of this change was actually on the Swift side: the incorrect diagnostic (imported declaration 'NSUpArrowFunctionKey' could not be mapped to 'NSEvent.SpecialKey.upArrow.rawValue') is emitted by Swift. However, Clang also has some validation logic for these attributes, and if the validation failed, the attribute is removed from the decl and not passed over to Swift.

The Clang-side change was correct, so I'm bringing it back as-is.

The Swift-side change rejected attributes that were previously accepted and are present in the SDK, so I made it more permissive this time.