Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
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.
`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
`_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.
CfgTraits was reverted almost two weeks ago upstream but will presumably
come back. See: e025d09b216dc2239e1b502f4f277abb6fb4648a
The PPC MMA clang types were added nine days ago.
The stdlib is still crashing deep in LLVM:
```
swifterror value can only be loaded and stored from, or as a swifterror argument!
%swift.error** %2
%7 = bitcast %swift.error** %2 to %swift.opaque*
in function $ss7DecoderP16unkeyedContainers015UnkeyedDecodingC0_pyKFTj
```
From a lldb session, the function in question:
```
define protected swiftcc void @"$ss7DecoderP16unkeyedContainers015UnkeyedDecodingC0_pyKFTj"(%Ts24UnkeyedDecodingContainerP* noalias nocapture sret %0, %swift.opaque* noalias nocapture swiftself %1, %swift.error** noalias nocapture swifterror dereferenceable(8) %2, %swift.type* %3, i8** %4) #0 {
%6 = bitcast %Ts24UnkeyedDecodingContainerP* %0 to %swift.opaque*
%7 = bitcast %swift.error** %2 to %swift.opaque*
tail call swiftcc void @"$sSK5index6before5IndexQzAD_tFTj"(%swift.opaque* noalias nocapture sret %6, %swift.opaque* noalias nocapture %1, %swift.opaque* noalias nocapture swiftself %7, %swift.type* %3, i8** %4) #0
ret void
}
```
After f721e0582b158c60c56d2601235b6d60758f4d7a in llvm it's now called
isInLocalScopeForInstantiation() and returns false if the context is not
dependent on a template parameter, so doesn't have the desired behavior for the
single swift caller in the clang importer.
This pulls out the old logic into a new static isLocalScope() function in
ClangAdapter.cpp.
In apple/llvm-project 9e7b7cbbbdb59d53136c0480f17cfe6ecef94163
(llvm/llvm-project ecd682bbf5e69e8690b7e3634258f05ae0a70448), BFloat16
was added to the clang builtins.
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.
...rather than replacing particular macros with an 'annotate'
attribute and then looking for that. This isn't /really/ any
particular win except maybe ever-so-slightly faster module imports
(with one fewer attribute being added to each declaration in a
mixed-source header).
This doesn't remove the SWIFT_CLASS_EXTRA, SWIFT_PROTOCOL_EXTRA, or
SWIFT_ENUM_EXTRA macros from PrintAsObjC (note that
SWIFT_EXTENSION_EXTRA was never used). They're not exactly needed
anymore, but they're not doing any harm if someone else is using them.
Clang r368413 introduced the SVE builtin types; update various switch
statements to handle them. This assumes that the types should not be
mapped into Swift, similar to the OpenCL types.
(cherry picked from commit 096e7ae96c)
Refactor the PlatformAvailability logic for determining
which Clang availability attributes are relevant when importing. The goal
is to separate the logic for attribute relevance for a given platform from
the logic to determine whether a deprecated attribute should be imported as
unavailable in Swift.
This also makes it possible for the "deprecated-as-unavailable" logic to
refer to the underlying Clang declaration, which is functionality that will
be used in a later commit.
This commit has no intended functional change.
Part of rdar://problem/48348822
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
These new types are not yet imported for Swift but they need to be
included in the switch cases to avoid -Wswitch warnings that get promoted
to errors when building with -Werror.
Clang r331244 added experimental support for a proposed char8_t type.
It is currently enabled only with a special flag so this change for
Swift only attempts to get the compiler to build, not to make use of
the new type.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
This is an opencl type that we did not use in the compiler anyways. Our only use
was to make sure that we had covered switches on clang builtin types (and
asserted if we ever hit that case in a switch).
Don't bail out early when there's no deprecated-as-unavailable mode;
we also use the loop to check for `availability(swift, unavailable)`.
No test because the only callers are for Objective-C declarations.
