Some of the tests now depend on features provided by Swift Syntax, and
will fail to pass if building without Swift Syntax support.
This commits marks all the tests I know fail to pass when Swift Syntax
is disabled.
- #70281 modified `ASTGen/verify-parse.swift`
- #70287 created `refactoring/SyntacticRename/operator.swift` and `SourceKit/RelatedIdents/operator.swift`
- #70389 modified `SourceKit/Refactoring/basic.swift` and indirectly
modified all `refactoring/ExtractFunction/*` tests.
Refactor `addSyntacticRenameRanges`, adding comments to make it easier to follow and remove its dependency on the `IsFunctionLike` parameter in `RenameLoc`.
This allows building sourcekitd and swift-refactor with `SWIFT_BUILD_SWIFT_SYNTAX=NO`. In these builds, the `relatedidents` and `find-syntactic-rename-ranges` requests will always return an error.
I will remove the `syntactic-rename` refactoring action in a follow-up commit. Clients should always ask for rename ranges and perform the rename by themselves instead of asking for a renamed file.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Previously we were skipping the macro’s definition (i.e. the part after `=` in a macro declaration if it wasn’t type checked. Since syntactic rename doesn’t type-check anything, it was thus skippin the macro definition. Add a flag to `ASTWalker` that allows `NameMatcher` to opt-out of this behavior.
Retrieving local rename ranges and the local rename refactoring both had
almost identical methods, except for the addition of retrieving the
outermost shadowed decl that was added a couple months back. Merge them.
Resolves rdar://106529370.
Update rename to pull the outermost-declaration so that references are correctly found.
Rather than keeping suppressed locations in the current parent, keep
them for the whole index. Local rename starts the lookup from the
innermost context it can, which could be a closure. In that case there
is no parent decl on the stack and thus no where to store the locations
to suppress. We could have a specific store for this case, but there
shouldn't be that many of these and they're relatively cheap to store
anyway.
Resolves rdar://104568539.
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
Generating a memberwise init would skip over properties with property wrappers. Switch the implementation of memberwise init generation closer to the one that generates the implicit memberwise init by also using `getMembers()` instead of `getStoredProperties()`.
rdar://89057767
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
If the enum has a raw value, `E` passed in to `BinaryExpr` is a `DeclRefExpr`, not a `DotSyntaxCallExpr`, so we crashed on `dyn_cast<DotSyntaxCallExpr>(E->getFn())->getFn()`.
Only look through `DotSyntaxCallExpr` if `E` is indeed a `DotSyntaxCallExpr`. While at it, fix a few other potential sources of nullptr crashes.
rdar://84707973
Since this implementation is exposed to users, we want to make it nice.
* Don't use 'unsafelyUnwrapped' which is usually not recommended to use
* Don't access 'container.allKeys' multiple times as it's a computed
property
rdar://89150202
Generalize the logic to handle different BlockKinds,
and add binding logic that lets us assign `true` or
`false` to the given bool success param in the
fallback case.
If we have a known bool flag parameter, drop it
from the success parameters being bound in a
refactored await call, as the async variant drops
it.
rdar://81896460
The async refactorings should not try to unique '_' when it's used as
the parameter name. Also skip adding a let binding to the `catch` if the
error parameter is '_'.
Resolves rdar://82158389
Convert Function to Async is available on an async function. It could be
useful to run this refactoring still, as it would attempt to convert any
completion-handler functions to their async alternatives. Keep allowing
this, but make sure not to re-add "async" to the function declaration.
Resolves rdar://82156720
