`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
The `equals_lower` API was replaced with `equals_insensitive` in llvm
commit 2e4a2b8430aca6f7aef8100a5ff81ca0328d03f9 and
3eed57e7ef7da5eda765ccc19fd26fb8dfcd8d41.
Ran git clang-format.
(cherry picked from commit e21e70a6bf)
When a completion-handler parameter has text before, e.g.,
"WithCompletionHandler", put the extra text on the base name rather
than the corresponding parameter. This ensures that we don't lose the
detail from the text, but always put it into a consistent place.
Extend the set of completion-handler names we look for to infer an
`async` import of an Objective-C method, which includes:
* (with)CompletionBlock
* (with)reply
* (with)replyTo
both as parameter names and as base name suffixes.
When a completion handler parameter has a selector piece that ends with
"WithCompletion(Handler)", prepend the text before that suffix to the
base name or previous argument label, as appropriate. This ensures that
we don't lose information from the name, particularly with delegate names.
Turns out self-type-stripping /always/ operates on a type without
prefixes rather than /never/. Neither of these behaviors are really
what we'd want, but we'll live with it!
rdar://problem/56334797
Yeah, SmallVectorImpl<char> is less convenient to work with, but
that's no reason to write out a stack buffer and then do a copy.
No functionality change.
All of the remaining name-matching logic is case-insensitive, and
the resulting name will have a stronger form of lowercasing applied
anyway, so we can leave the name with a leading uppercase letter in
its intermediate state. Slightly less pure, but also slightly less
code and slightly less memory use.
Method base names are where the most complicated logic is, so let's
split it out from the other cases a bit. Also makes early returns more
explicit.
No intended functionality change.
Previously this was /also/ called 'omitNeedlessWords'. Rename it to
avoid confusion and better describe the particular step it's taking.
I don't love the "with special cases" but I think it's important to
note that this isn't an exact parallel of matchLeadingTypeName.
This is the only omission kind that needs to look in the middle of a
name rather than just at the start or the end. So, handle that
explicitly instead to simplify all the other code.
Separate the functional searching bit from the actual "omitting" bit
once the type name is matched. This in turn provides a good place to
flip from reverse iterators back to forward iterators, making the
following code about omitting a fair bit clearer.
No functionality change. This is 90% moving things around and 10%
rephrasing.
The diagnostic is now a warning and the new message alerts the user that
though it is valid to have let and var as argument label names,
they are interpreted as argument labels, not keywords.
When in Swift 3 Compatibility Mode we now acceptable a standalone
'$' as an identifier. In all other cases this is now disallowed
and must be surrounded by backticks.
We don't want the machine calling conventions for closure invocation functions to necessarily be tied to the convention for normal thin functions or methods. NFC yet; for now, 'closure' follows the same behavior as the 'method' convention, but as part of partial_apply simplification it will be a requirement that partial_apply takes a @convention(closure) function and a box and produces a @convention(thick) function from them.
