The current implementation of `-application-extension` has a problem that affects the generation of ObjC headers for regular Swift modules.
The primary purpose of `-application-extension` is to prevent the use of unavailable APIs in app extensions. However, it has an impact on the generation of -Swift.h headers and exposes Swift's internal declarations to ObjC. This behavior is appropriate for mixed modules that are not consumed externally, such as app extensions, but it fails to address the situation when a module is not an extension itself but is consumed by the extension (c90cd11).
To resolve this issue while maintaining the desired behavior, we can introduce a new flag for this particular use-case.
When a module is imported @_weakLinked, its re-exported peer modules
have their definitions imported with strong linkage which can often
defeat the point of weak linking the parent in the first place. Allow
the weak-linkage to float to the immediate re-exports of the @_weakLinked
module.
Resolves rdar://117166194
Use the same pattern as 'getAllMembers()'. This supports nested macro
expansion:
```
std::function<void(Decl *)> visit;
visit = [&](Decl *d) {
doIt(d);
d->visitAuxiliaryDecls(visit);
};
for (auto *d : decls)
visit(d);
```
Don't visit auxiliary decls in `PrintAST::visit(Decl *)` this function
is only intended for single decl printing. The caller should visit them
separately. For that, add
`ModuleDecl::getTopLevelDeclsWithAuxiliaryDecls()`
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
This implementation has the function execute a request to scan the
inheritance clause of non-protocol nominals for a `~Copyable`. For
protocols, we look in the requirement signature.
This isn't our final state, as the GenericEnvironment needs to be
queried in general to determine of a Type is noncopyable. So for now
checking for a `~Copyable` only makes sense for Decls.
I've renamed the method to `TypeDecl::isNoncopyable`, because the query
doesn't make sense for many other kinds of `ValueDecl`'s beyond the
`TypeDecl`'s. In fact, it looks like no one was relying on that anyway.
Thus, we now have a distinction where in Sema, you ask whether
a `Type` or `TypeDecl` is "Noncopyable". But within SIL, we still
preserve the notion of "move-only" since there is additionally the
move-only type wrapper for types that otherwise support copying.
I think from SIL's perspective, it should only worry about whether the
type is move-only. That includes MoveOnlyWrapped SILTypes and regular
types that cannot be copied.
Most of the code querying `SILType::isPureMoveOnly` is in SILGen, where
it's very likely that the original AST type is sitting around already.
In such cases, I think it's fine to ask the AST type if it is
noncopyable. The clarity of only asking the ASTType if it's noncopyable
is beneficial, I think.
- Add a flag to the serialized module (IsEmbeddedSwiftModule)
- Check on import that the mode matches (don't allow importing non-embedded module in embedded mode and vice versa)
- Drop TBD support, it's not expected to work in embedded Swift for now
- Drop auto-linking backdeploy libraries, it's not expected to backdeploy embedded Swift for now
- Drop prespecializations, not expected to work in embedded Swift for now
- Use CMO to serialize everything when emitting an embedded Swift module
- Change SILLinker to deserialize/import everything when importing an embedded Swift module
- Add an IR test for importing modules
- Add a deserialization validation test
For property declarations, the `@_spi` attribute is attached to the VarDecl AST
node, rather than the PatternBindingDecl AST node, so the `isSPI()` query
should take this into account. Failing to do so caused the availability checker
to erroneously require that `@_spi` properties of types in `-library-level api`
libraries have availability annotations.
Resolves rdar://113587321.
Within one module, SPI decls are always visible. Conceptually we want
the same behavior for `@_private` imports where the client pretends it's
part of the same module.
rdar://81240984
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
Eliminate the error message
error: global freestanding macros not yet supported in script mode
by implementing name lookup, type checking, and code emission for
freestanding macros. The key problem here is that, in script mode,
it is ambiguous whether a use of a freestanding macro is an expression
or a declaration. We parse as an expression (as we do within a
function body), which then gets wrapped in a top-level code
declaration.
Teach various parts of the compiler to look through a top-level code
declaration wrapping a macro expansion expression that is for a
declaration or code-item macro, e.g., by recording these for global
name lookup and treating their expansions as "auxiliary" declarations.
Fixes rdar://109699501.
stated in the original source.
If an extension macro can introduce protocol conformances, macro expansion
will check which of those protocols already have a stated conformance in the
original source. The protocols that don't will be passed as arguments to
extension macro expansion, indicating to the macro that it should only add
conformances to those protocols.
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.
Macro-generated extensions are hoisted to file scope, because extensions are
not valid in nested scopes. Callers of 'visitAuxiliaryDecls' assume that the
auxiliary decls are in the same decl context as the original, which is clearly
not the case for extensions, and it leads to issues like visiting extension at
the wrong time during SILGen. The extensions are already added to the top-level
decls, so we don't need to visit them as auxiliary decls, and we can type-check
macro-expanded decls at the end of visitation in TypeCheckDeclPrimary.
* Don't invalidate the lookup cache in 'getOrCreateSynthesizedFile()'
Adding a synthesized file itself doesn't introduce any decls. Instead,
we should invalidate the right after the actual declrations are added
in the file
* Remove 'SourceLookupCache::invalidate()' method. It was just used
right before the destruction. It was just not necessary
* Include auxiliary decls in 'SourceLookupCache::lookupVisibleDecls()'
Previously, global symbol completion didn't include decls synthesized
by peer macros or freestanding decl macros
* Include "auxiliary decls" in visible member lookup, and visible local
decl lookup
* Hide macro unique names
rdar://110535113
`lib/swift/host` contains modules/libraries that are built by the host
compiler. Their `.swiftmodule` will never be able to be read, ignore
them entirely.
