Accessors logically belong to their storage and can be synthesized
on the fly, so removing them from the members list eliminates one
source of mutability (but doesn't eliminate it; there are also
witnesses for derived conformances, and implicit constructors).
Since a few ASTWalker implementations break in non-trivial ways when
the traversal is changed to visit accessors as children of the storage
rather than peers, I hacked up the ASTWalker to optionally preserve
the old traversal order for now. This is ugly and needs to be cleaned up,
but I want to avoid breaking _too_ much with this commit.
We used to have a function getRootAndResultTypeOfKeypathDynamicMember to return
both the root and result type of a subscript. This patch splits the function
into two functions returning root type and result type respectively. It also refactors
the implementation into the evaluator model.
ModelASTWalker was previously constructing SyntaxNodes for EnumElementDecls
manually when visiting their associated EnumCaseDecl so that they would appear
as children rather than siblings. It wasn't actually walking these nodes
though, so missed handling some things, e.g. closures passed as default
argument values. These were also still being visited later, and because the
first visit consumed all the associated TokenNodes, this was triggering an
assertion due to the associated TokenNodes not matching expectations.
IDE functionality needs some internal type checking logics, e.g. checking
whether an extension is applicable to a concrete type. We used to directly
expose an header from sema called IDETypeChecking.h so that IDE functionalities
could invoke these APIs. The goal of the commit and following commits is to
expose evaluator requests instead of directly exposing function entry points from
sema so that we could later move IDETypeChecking.h to libIDE and implement these functions
by internally evaluating these requests.
let _: [Foo] = [
.create(str: Int)
.create(#^COMPLETE^#)
]
Previously, this completion used to fail because the array expression
isn't typechecked. We need to analyze the context type of the array
literal first, that defines the type of the unresolved member
expression.
rdar://problem/50696432
Resolving cursor info is a necessary step both when checking the availability
of a refactoring kind and performing the refactoring action. These
two steps are two high-level sourcekitd requests issued from IDE.
By caching the result of the resolved cursor info in the evaluator of
the ASTContext, we can reuse the cursor info result across these separate
IDE requests.
Comparing the start and end of ranges doesn't work in all cases since
both a < b and b < a can be true if a = b. This behavior was causing an
assertion fail in the Windows standard library which while sorting,
asserts that if `a < b`, then `!(b < a)` in debug mode.
Since ranges don't overlap otherwise, comparing just the starts of the
ranges will properly sort them.
A number of callers to AbstractFunctionDecl::getBody() were only
extracting the source range of the body... which can be retrieved more
efficiently with getBodySourceRange().
struct Wrap<T> {
func method<U>(_ fn: (T) -> U) -> Wrap<U> {}
}
func testGenricMethodOnGenericOfArchetype<Val>(value: Wrap<Val>) {
value.method(#^HERE^#)
}
In this case, the type of value is `Wrap<Val[archetype]>`.
`Type::getTypeOfMember()` for 'method' method returns
`( (Val[archetype]) -> U[generic param]) -> Wrap<U[generic param]>`
which crashs 'mapTypeIntoContext()' because it already hass archetype.
rdar://problem/52386176
```swift
protocol Proto {}
struct ConcreteProto {}
struct MyStruct<T> {}
extension MyStruct where T: Proto {
static var option: MyStruct<ConcreteProto> { get }
}
func foo<T: Proto>(arg: MyStruct<T>) {}
func test() {
foo(arg: .#^HERE^#)
}
```
In this case, the type of `MyStruct.option` is `MyStruct<ConcreteProto>`
whereas the context type is `MyStruct<T> where T: Proto`.
When checking the convertibility of them , we need to "open archetype types".
rdar://problem/24570603
rdar://problem/51723460
The backing property for 'foo' is now '_foo', and the projected value '$foo'.
This updates Indexing to report occurrences of foo within both $foo and
_foo occurrences (rather than just $foo - the old _foo).
FindRelatedIdents was similarlar updated, so it reports 'foo' ranges in both
_foo and $foo.
CursorInfo now reports the USR, documentation, and location of foo when invoked
occurrences of $foo or _foo, but now leaves the name, type, and annotated
declaration of _foo/$foo as is. Having the same USR ensures rename invoked on
any of them will still rename via foo. Reporting foo's documentation comment
instead is just to present something more useful to the user.
Make sure they handle the case when a property wrapper type's constructor is
called with the first argument coming from the var initializer, and the rest
from the custom attribute's argument.
This is the final piece to get rename and findRelatedIdents to include all foo
and $foo occurrences, for example, in the set of occurrences to be renamed or
shown, regardless of whether they were initiated on a foo or $foo.
Resolves rdar://problem/51695783.
This patch achieves this by updating indexing to reporting the position of
`foo` in occurrences of `$foo` as an occurrence of the `foo` symbol, so
that renames initiated on occurrences of the `foo` symbol will also result
in occurrences of the `$foo` symbol being updated correctly. This also means
find-references on foo will show places where $foo is used.
Making rename work in the other direction (invoking rename on $foo upating foo
occurrences too) is still todo.
This fixes custom attribute syntax highlighting on parameters and functions
(where function builders can be applied). They weren't being walked in
the function position previously and were walked out of source order in the
parameter position.
It also fixes rename of the property wrapper and function builder type
names that can appear in custom attributes, as well as rename of property
wrapper constructors, that can appear after the type names, e.g.
`@Wrapper(initialValue: 10)`. The index now also records these constructor
occurrences, along with implicit occurrences whenever a constructor is
called via default value assignment, e.g. `@Wrapper var foo = 10`, so that
finding calls/references to the constructor includes these locations.
Resolves rdar://problem/49036613
Resolves rdar://problem/50073641
In parser, 'parseExprPostfixSuffix()' can parse postfix expression for
'super'. 'parseExprSuper()' doesn't need to parse them.
In code-completion, 'completeExprSuper()' and 'completeExprSuperDot()'
can be consolidated to 'completePostfixExpr()' and 'completeDotExpr()'.