LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
This change makes sure that `NSNotification.Name.NEVPNStatusDidChange` is imported correctly when C++ interop is enabled.
`importer::findSwiftNewtype` is called while writing Clang modules, at a point when the translation-unit scope does not exist (`clangSema.TUScope` is `nullptr`).
That prevents the Clang lookup from discovering `NSNotificationName` declaration.
Instead of trying to pass a translation-unit scope to Clang, let's use qualified name lookup which does not require a scope.
rdar://112199372
Clang and LLVM added some new builtins.
LLVM added IITDescriptor::AArch64Svcount, which I set to not be
decodable since Swift can't represent those at the moment.
Also added handling for the WASM reference type builtins in the Clang
type converter.
LLVM deprecated, renamed, and removed a bunch of APIs. This patch
contains a lot of the changes needed to deal with that.
The SetVector type changed the template parameters.
APInt updated multiple names, countPopulation became popcount,
getAllOnesValue became getAllOnes, getNullValue became getZero, etc...
Clang type nullability check stopped taking a clang AST context.
The LLVM IRGen Function type stopped exposing basic block list directly,
but gained enough API surface that the translation isn't too bad.
(GenControl.cpp, LLVMMergeFunctions.cpp)
llvm::Optional had a transform function. That was being used in a couple
of places, so I've added a new implementation under STLExtras that
transforms valid optionals, otherwise it returns nullopt.
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
