`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
`%build-clang-importer-objc-overlays` builds the
overlays for the current target rather than the
host, so update the `%refactor` invocations to
take the target as an argument.
rdar://81128571
Update the async refactoring tests in `convert_function.swift` to
compile the refactored code (where possible) to check for errors. This
would have prevented the issue with the refactored `Result<Void, ...`>
handler producing erroneous code.
When adding an async alternative for a function with a
`(Result<Void, ...>) -> Void` completion handler, the legacy body was
adding a call to the handler with `.success(result)`. We don't assign to
`result` for `Void` handlers, so pass `()` instead.
Resolves rdar://81829392
Update the async refactorings to use the name from the async alternative
if one is known, rather than always assuming the name matches the
synchronous function.
Note that this could also be used to determine whether results remain
optional or not, but that has been left for a future patch.
Resolves rdar://80612521
Instead of a new attribute `@completionHandlerAsync`, allow the use of
the existing `renamed` parameter of `@available` to specify the
asynchronous alternative of a synchronous function.
No errors will be output from invalid names as `@completionHandlerAsync`
had, but if a function is correctly matched then it will be used to
output warnings when using the synchronous function in an asynchronous
context (as before).
Resolves rdar://80612731
