[CursorInfo] Implement a few expression references as solver-based

[ahoppen]

This implements cursor info resolving for a few expression types using the constraint system. This allows us to detect ambiguous results – we cannot deliver them yet but that will be done in a follow-up PR.

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

Stress tester failure at SceneDelegate.swift:unmodified:1981 is an improvement. A reduced reproducer is

protocol MyProto {
    static func makeInstance() -> Self
}

class Base: MyProto {
    static func makeInstance() -> Self {
        fatalError()
    }
}

class Inherited: Base {
    var member: Int
}

// RUN: %sourcekitd-test -req=cursor -pos=%(line + 2):30 %s -- %s
func foo() {
    Inherited.makeInstance().member = 2
}

The AST-based implementation reported Base as the receiver type, the solver-based implementation reports Inherited, which is correct.

[ahoppen]

Stress tester failure at SceneDelegate.swift:concurrent-708:703 is an improvement.

The AST-based implementation reported shared as a class variable, but it’s spelled as a static variable in source.

[ahoppen]

Stress tester failure at APIService.swift:unmodified:3766 is an improvement.

In the AST-based implementation on async in DispatchQueue.main.async no receiver was reported, the solver-based implementation reports OS_dispatch_queue.

[bnbarham]

The AST-based implementation reported Base as the receiver type, the solver-based implementation reports Inherited, which is correct.

I wouldn't expect any receiver type here, it's statically resolvable. If the old implementation is returning dynamic here I'd say that's a bug.

In the AST-based implementation on async in DispatchQueue.main.async no receiver was reported, the solver-based implementation reports OS_dispatch_queue.

Is DispatchQueue.async @objc? If it isn't then as it's defined in an extension, it isn't overridable, and thus shouldn't be dynamic or have a receiver. As far as I can tell, it isn't, though maybe we're just missing the annotation in the generated interface.

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

Note to self: The stress tester only found failures in refactoring where previously we didn’t report any cursor, so all of those are improvements.

[ahoppen]

@swift-ci Please smoke test

[rintaro]

Re: !isa<VarDecl>(D), does this affect class computed values? e.g.

class C {
  class var value: Int { 1 }
}

[rintaro]

Suggested change

	while (auto Identity = dyn_cast<IdentityExpr>(Base)) {
	Base = Identity->getSubExpr();
	}
	Base = Base->getSemanticsProvidingExpr();

[rintaro]

Use ReceiverTy = ReceiverTy->getWithoutSpecifierType() that handles both LValueType and InOutType.
Also for MetatypeType, we might want to consider using ReceiverTy->getMetatypeInstanceType()

[ahoppen]

@swift-ci Please smoke test

[rintaro]

Forgot to remove?

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please SourceKit stress test

[ahoppen]

@swift-ci Please smoke test Windows