This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of https://github.com/apple/swift/issues/65726
Fixes: https://github.com/apple/swift/issues/64598
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
This lets us consolidate code paths that mostly run in parallel over the
existing InOutTypeRepr/SharedTypeRepr/OwnedTypeRepr family of types. This
patch by itself is NFC but makes it easier to introduce new spellings,
particularly the newly-official `borrowing` and `consuming` modifiers
that were approved in SE-0377.
`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
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
A keypath using dynamic member lookup results in various `KeyPathExpr`
that have components with no location. Ignore these and any other
references that have a missing location.
Resolves rdar://85237365
SemaAnnotator was walking into an autoclosure and then manually running
`passReference` on the unwrapped expression without walking it. Since
its synthesized anyway, skip walking the autoclosure entirely and walk
the unwrapped expression instead.
Fix `swift::ide::isBeingCalled` to look through `IdentityExpr`s and
`swift::ide::getBase` also not unwrapping curry thunks.
Resolves rdar://81312849
TypeCheckPattern used to splat the interface type into this, and
different parts of the compiler would check one or the other. There is
now one source of truth: The interface type. The type repr is now just
a signal that the user has written an explicit type annotation on
a parameter. For variables, we will eventually be able to just grab
this information from the parent pattern.
A number of callers to AbstractFunctionDecl::getBody() were only
extracting the source range of the body... which can be retrieved more
efficiently with getBodySourceRange().
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
When users override a SDK function whose parameter types have been changed,
we should introduce a local variable in the body of the function definition
to shadow the changed parameter. Also, a proper conversion function should
be applied to bridge the parameter to the local variable.
rdar://41828411
Some raw representable struct from SDK can be initialized without
explicit labels (rawValue:). When their types have been changed to type
alias, we should migrate the initializer calls to the argument alone.
In Swift 4.2 the second parameter of UIApplicationMain exactly matches the type
of CommandLine.unsafeArgv so it can be called as below:
UIApplicationMain(CommandLine.argc, CommandLine.unsafeArgv, ...)
This is how it was intended to be in Swift 4 as well, but the types had
optionality differences, so callers instead had to do something like the below
example from the Firefox-iOS project:
let pointer = UnsafeMutableRawPointer(CommandLine.unsafeArgv).bindMemory(
to: UnsafeMutablePointer<Int8>.self, capacity: Int(CommandLine.argc))
UIApplicationMain(CommandLine.argc, pointer, ...)
This migration simply replaces the the second argument with
CommandLine.unsafeArgv if the first argument is CommandLine.argc.
There is an open issue for providing a deprecated version with the old type so
we simply leave as is any callers that don't pass argc for the first argument.
Resolves rdar://problem/40045693.
When inserting conversion functions around expressions, we should check
whether the type of the expression is a recognized name alias that is
known to be changed to raw-value representable type. We should avoid
inserting conversion functions in this case because doing so causes
build errors.
resolves: rdar://40463990
if users' member access doesn't specify the base name. rdar://40373279"
Previously, we saw that unconditionally omitting type names can lead to
build errors (rdar://40458118). This revised fix omits type names only when
the new member name is identical to the old one.
By postponing the insertion of conversion function calls, we can filter
out the expressions that require more than one helper function wrapper.
resolves: rdar://40979943
We used to assert migration scripts exist. This patch further
decouples these scripts and the compiler by treating missing scripts
as a regular compiler error.
Related: rdar://40538097
