Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
CountAttributedType and TypeCoupledDeclRefInfo are new Clang type
and type metadata created for types with the 'counted_by' attribute
that shouldn't be accessible from Swift right now. Hence, marking
them unreachable.
SILOptions::EnableSerializePackage info is lost.
SILVerifier needs this info to determine whether resilience
can be bypassed for decls serialized in a resiliently
built module when Package CMO optimization enabled.
This PR adds SerializePackageEnabled bit to Module format
and uses that in SILVerifier.
Resolves rdar://126157356
Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
When caching is enabled with include-tree, the bridging header PCH is
created from the include tree directly. Setup the rewriter correctly
when embedding the bridging header into swift binary module.
rdar://125719747
LLVM is gearing up to move to `std::endianness` and as part of that has
moved `llvm::support::endianness` to `llvm::endianness`
(bbdbcd83e6702f314d147a680247058a899ba261). Rename our uses.
Protocols with a superclass bound written as `protocol P where Self: C`
return null from getSuperclass(). Unqualified lookup only cares about
getSuperclassDecl(), so serialize that instead.
Fixes rdar://problem/124478687.
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.
We preserve the current semantics that we have today by requiring that either all SILResultInfo are transferring or none are transferring. This also let me swap to @sil_transferring representation.
I did both of these things to fix SIL issues around transferring.
It also ensures that we now properly emit
Our standard conception of suppressible features assumes we should
always suppress the feature if the compiler doesn't support it.
This presumes that there's no harm in suppressing the feature, and
that's a fine assumption for features that are just adding information
or suppressing new diagnostics. Features that are semantically
relevant, maybe even ABI-breaking, are not a good fit for this,
and so instead of reprinting the decl with the feature suppressed,
we just have to hide the decl entirely. The missing middle here
is that it's sometimes useful to be able to adopt a type change
to an existing declaration, and we'd like older compilers to be
able to use the older version of the declaration. Making a type
change this way is, of course, only really acceptable for
@_alwaysEmitIntoClient declarations; but those represent quite a
few declarations that we'd like to be able to refine the types of.
Rather than trying to come up with heuristics based on
@_alwaysEmitIntoClient or other sources of information, this design
just requires the declaration to opt in with a new attribute,
@_allowFeatureSuppress. When a declaration opts in to suppression
for a conditionally-suppressible feature, the printer uses the
suppression serially-print-with-downgraded-options approach;
otherwise it uses the print-only-if-feature-is-available approach.
