For enum cases with associated values, their construction is modelled by a function. E.g. if you have
```swift
enum Foo {
case first(associated: Int)
}
```
then `Foo.first` is a function of type `(Int) -> Foo`. But if you write `Foo.first(associated: 2)` in source code, we consider this construct as a referenced, not a call. This causes us to miss renaming of associated value labels during local refactoring.
rdar://84061868
Previously, we only walked the parent scope of the decl context that declared the value to rename if it was a TopLevelCodeDecl. But also functions can have locally declared types that can be used in sibling scopes. Thus, we always need to walk the parent DeclContext of the one declaring the value we are renaming.
rdar://89836229
The removed `else if` branch caused the argument to the `-` operator to be be reported as `Mismatch`. I couldn’t figure out what that branch was for, so I removed it.
rdar://91588948
Inside capture lists like `{ [test] in }`, `test` refers to both the newly declared, captured variable and the referenced variable it is initialized from. We currently try to rename it twice, yielding invalid, confusing results. Make sure to only record this situation once.
Fixes rdar://78522816 [SR-14661]
We weren't renaming all occurrences of 'x' in the cases like the below:
case .first(let x), .second(let x):
print("foo \(x)")
fallthrough
case .third(let x):
print("bar \(x)")
We would previously only rename occurrences within the case statement the query
was made in (ignoring fallthroughs) and for cases with multiple patterns (as in
the first case above) we would only rename the occurrence in the first pattern.
Set local discriminator for all local `VarDecl`s. Otherwise, they cannot
be discriminated with USRs. This change is needed for rename refactoring which
uses USR for discrimiating variable names.
https://bugs.swift.org/browse/SR-7205,
rdar://problem/34701880
