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.
`_Nullable_result` indicates that a parameter of a completion handler
should be imported as optional when the completion handler can fail by
throwing an error.
Implements rdar://70108088.
In C, a function can be declared at local scope:
void aFunctionInBase(void) {
void theFunctionInQuestion(int);
}
and then again in a different header at top-level scope:
void theFunctionInQuestion(int);
If the first one appears first, it becomes what Clang considers the
"canonical" declaration, which (up until now) Swift has been using to
decide what module to import a function into. (Since a C function can
be redeclared arbitrarily many times, we have to pick one.) This is
important for diagnostics and anything else that might ask "where did
this Swift declaration come from". Instead of the very first
redeclaration, use the first non-local one to determine the "home"
module.
(The standard library wants a guarantee that forward declarations they
put in SwiftShims won't interfere with declarations found elsewhere. I
don't think Clang can /ever/ provide that, so if there's ever a
mismatch between the standard library's forward declarations and the
"real" declarations the standard library's might win out at the LLVM
level---say, in terms of attributes. But this at least removes a place
where that could be visible to users even when it isn't otherwise a
problem.)
Previously we only did this for factory methods, but there's no reason
why we can't do it for regular init methods too, and doing so
simplifies the signature of SwiftDeclConverter::importConstructor.
Also remove some indirection through helper functions in ClangAdapter.
These were more useful back when Swift looked directly at API notes
instead of relying on Clang turning them into attributes; now they're
just an extra hop for no reason.
The only place this was used in Decl.h was the failability kind of a
constructor.
I decided to replace this with a boolean isFailable() bit. Now that
we have isImplicitlyUnwrappedOptional(), it seems to make more sense
to not have ConstructorDecl represent redundant information which
might not be internally consistent.
Most callers of getFailability() actually only care if the result is
failable or not; the few callers that care about it being IUO can
check isImplicitlyUnwrappedOptional() as well.
Remove all occurrences of a "useSwift2Name" bool, and replace it with
version plumbing. This means that ImportDecl is now entirely
version-based, and the importer Impl knows versions. This will be
needed for marking Swift 3 names as deprecated, when there is a new
Swift 4 name.
NFC.
If the keyword 'static' also appears within the '[' and ']' of the
array type derivation, then for each call to the function, the
value of the corresponding actual argument shall provide access to
the first element of an array with at least as many elements as
specified by the size expression. (C11 6.7.6.3p7)
Limit this change to Swift 4 so as not to break existing code, though
use of 'static' in this way is rare to begin with and passing nil
would probably be an error anyway.
Small part of rdar://problem/25846421.
Swift side of this new flag. This allows Objective-C framework authors
to replace a pair of methods by properties without breaking source
compatibility. This is especially important for class properties,
which were only introduced last year.
Still to come: importing the accessors even when this flag isn't set,
in order to provide better QoI when migrating from a method interface
to a property interface.
Part of rdar://problem/28455962
Name Importer wraps references to the Swift context and other needed
encapsulation. The eventual goal is to allow name lookup tables to
live separately from the Impl, and do better Clang-instance-based
caching in the future, as well as general separation of concerns.
NFC
Pull omitNeedlessWordsInFunctionName off of the Impl, and into a
static function local to ImportName.cpp. Separate it out from the Impl
entirely. Though this adds a couple of extra ugly parameters, it's one
of the last bits of tie-in between importFullName and the Impl.
By refactoring out PlatformAvailability from the ClangImporter, we can
more easily refactor out isUnavailableInSwift from the impl, which
will free us up to do more flexible import naming.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
