Fix @dynamicMemberLookup for protocol/archetype types.

[dan-zheng]

Enable subscript(dynamicMember:) as a requirement for @dynamicMemberLookup protocols.

Previously, @dynamicMemberLookup protocols could only define subscript(dynamicMember:) in an extension. This patch fixes that.

@dynamicMemberLookup
protocol DynamicProtocol {
  // This works now.
  subscript(dynamicMember name: String) -> Self { get }
}
// Previously, only this worked (method in protocol extension).
extension DynamicProtocol {
  subscript(dynamicMember name: String) -> Self { return self }
}

Resolves SR-8077.

There's also some @dynamicCallable-related gardening.

[dan-zheng]

@swift-ci Please smoke test

EDIT: Linux tests failed with a weird unrelated error: error: compilation involves pch was enabled in PCH file but is currently disabled.

[slavapestov]

@dan-zheng Take a look at extractDirectlyReferencedNominalTypes() in lib/AST/NameLookup.cpp. Do you think this can be useful for @dynamicCallable and @dynamicMemberLookup?

More generally it would be nice to factor out a common superclass/conforming protocol walk for use by name lookup and these attributes. If you think about it what they're doing is very similar to name lookup except they're searching for an attribute and not a member.

[dan-zheng]

@slavapestov Thanks for the suggestion!

extractDirectlyReferencedNominalTypes does seem useful. It populates a SmallVectorImpl with decls, but the order of the decls might not be ideal here - need to investigate.

A common superclass/protocol type walk function definitely makes sense. I'm happy to look into it, perhaps we can merge this PR to unblock progress in the meantime.

[dan-zheng]

I got some weird test failures regarding pch. Retriggering tests in hopes that things pass.
@swift-ci Please smoke test

[dan-zheng]

@shahmishal: you're probably aware of this already, but do you know why CI is failing with error: compilation involves pch was enabled in PCH file but is currently disabled?

Example build job.
CI for other PRs seems to fail with the same error currently.

[shahmishal]

@milseman Is this related to cherry-pick on clang/llvm branch?

[slavapestov]

@dan-zheng @shahmishal Jordan pushed a fix for the PCH issue, tests should pass now.

[slavapestov]

@dan-zheng Why would the order matter?

[dan-zheng]

@slavapestov It shouldn't, I was being overly cautious. 😃

EDIT: extractDirectlyReferencedNominalTypes is currently a fileprivate static function, would you recommend declaring it in NameLookup.h under the swift namespace?

I'll probably augment extractDirectlyReferencedNominalTypes and dedupe code for @dynamicCallable and @dynamicMemberLookup in a follow-up PR.

[dan-zheng]

@swift-ci Please smoke test

[slavapestov]

@dan-zheng Yeah, I would first make the function public and use it in the implementation of those attributes, and make sure there are no regressions, etc. Then I would think about extracting the nominal type visitation logic as a separate task.

[lattner]

I'm +1 on this patch (including the testcase), but am sufficiently far enough away from the code to not be the best reviewer. Is anyone else able to give this a sniff test?

[dan-zheng]

cc @slavapestov @rudkx: could you please review?

As suggested by Slava, in a follow-up PR, I plan to make extractDirectlyReferencedNominalTypes public and use it to dedupe type walking code in hasDynamicMemberLookupAttribute and getDynamicCallableMethods.

[dan-zheng]

Added a // SR-8077 test case comment in the test file.
@swift-ci Please smoke test

[dan-zheng]

Oops, accidentally committed this rogue comment.
I'll remove in my next PR, if it's not gone by then.
Removed in #20567.