immediately discard as non-viable any declarations that cannot be
called due to argument-label mismatch.
This heuristic already existed, but it was badly out-of-date vs.
the current language rules on argument-passing. Change it to use
the standard argument matching algorithm.
This greatly reduces the number of overloads we consider for certain
kinds of expression, most importantly explicit initialization syntax
('T(x)'). Ordinary type-matching will quickly reject such calls,
but backtracking will discard this rejection. Thus this heuristic
can greatly decrease the total work done by the type-checker when
something else in the system is causing a combinatorial explosion.
The diagnostic changes in the test-suite seem acceptable to me.
Shout-out to Doug for pointing out multiple places where I didn't
need to reinvent the wheel.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
Fixes a use-after-free when doing code-completion where the expected
type is an array of generic type (or any bound generic type).
takeArray<T>(x: [T]) {}
takeArray(foo.<here>)
rdar://problem/24521470
For a concrete type, members from its conforming protocols' extensions can be hard
to manually surface. In this commit, when printing Swift modules, we start to replicate these
extensions and synthesize them as if they are the concrete type's native extensions.
Credit to Doug for suggesting this practice.
Not all types are l-valuable, notably InoutType's. This seems like a
weird restriction to put in the type checker, but it is the cleanest
solution to this. The better solution would be to change how
inoutexpr/inouttype are represented completely... maybe someday.
This reverts commit b1a7ceaf4b.
Accounting for these operators can add complexity in some cases, so I'm
backing out this change pending a more holistic approach.
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
Note that the typecheck perf for these kinds of expressions still isn't fantastic, but at least they're now computationally feasible. I have further improvements planned for this area which should bring performance in line with expectations.
UnresolvedConstructorExpr is not providing any value here; it's
essentially just UnresolvedDotExpr where the name refers to an
initializer, so use that instead. NFC