By default package decls are treated as resilient, similar to public (non-frozen).
This PR adds support to allow direct access to package decls at use site if opted-in.
Requires the loaded module to be a binary module in the same package.
Resolves rdar://121626315
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
Introduce `AvailableDuringLoweringDeclFilter` which can be composed with
`OptionalTransformRange` to implement iterators that filter out unavailable
decls.
The restriction that default arguments be disallowed from accessing
`@usableFromInline` decls is overbearing for library developers who need to
write non-trivial code to compute a default value, since it forces them to
either write a verbose closure inline in the function signature or expose a
`public` helper function which unnecessarily expands API surface. A
`@usableFromInline` function a more reasonable way to encapsulate a verbose
default value computation.
This reverses the semantic changes included in https://github.com/apple/swift/pull/15666.
Resolves rdar://112093794.
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.
Calling `getInnermostDeclContext()->getParentSourceFile()` on a macro-produced decl does not seem to be a reliable way to obtain the macro expansion source file, because `PatternBindingDecl` is not a `DeclContext` and `getInnermostDeclContext()` falls back outside the macro expansion file. This patch switches to using `getSourceFileContainingLocation` when possible.
Resolves rdar://109376568.
* Weakly reference ModuleDecl from PackageUnit
* Add PackageUnit decl context getter and use it for a package AccessScope
* Return module decl referenced by PackageUnit in getModuleScopeContext and getParentModule
* Handle package acl in access scope checkers
* Remove AccessLimitKind
* Fix tests
Resolves rdar://104987295, rdar://105187216, rdar://104723918
Previously enum AccessLimitKind was
added to distinguish access scopes b/t package and public while keeping
DeclContext null but it proved to be too limiting. This PR creates package specific entries for DeclContext and
ASTHierarchy. It create a new class PackageUnit that can be set as the parent DeclContext of ModuleDecl. This PR
contains addition of such entries but not the use of them; the actual use of them will be in the upcoming PRs.
Resolves rdar://106155600
Previously, typechecking and SILGen would treat a function body as fragile as long as the declaration had a `@backDeployed` attribute, regardless of the platform specified by the attribute. This was overly conservative since back deployed functions are only emitted into the client on specific platforms. Now a `@backDeployed` function can reference non-`public` declarations on the platforms it is resilient on:
```
@backDeployed(before: iOS 15)
public func foo() {
#if os(iOS)
// Fragile; this code may be emitted into the client.
#else
// Resilient; this code won't ever be exposed to clients.
#endif
}
```
Resolves rdar://105298520
scopes.
ASTScope lookup can no longer assume that all scopes are within the same source
file. Scope trees can now contain scopes that are in macro expansion buffers, which
live in different source files with independent source ranges from the root of a
given scope tree. To handle this when searching for a scope containing a given source
location, ASTScope lookup needs to walk up the chain of macro expansion buffers to find
the lowest common buffer in which to compare source locations.
This fixes a number of issues with unqualified lookup into and from within macro-expanded
code.
With macro expansions, and really any code generation that produces
proper source locations, the parent source file of a declaration
context will be a generated source file rather than the source file
near the top of the declaration-context stack. Adjust the
implementation of `getParentSourceFile()` to return that innermost
source file by doing location-based lookup.
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Introduce a `getTopmostDeclarationDeclContext`
utility to ensure we ensure we don't visit a
`nullptr` DeclContext for an erroneous module
under `-experimental-allow-module-with-compiler-errors`.
Additionally, tweak the insertion location such
that we insert at the start of any attributes
present.
rdar://97267326
This simplifies the logic in `ide::typeCheckContextAt` and fixes an issue that prevent code completion from working inside variables that are initialized by calling a closure.
Fixes rdar://90455154 [SR-16012]
Fixes rdar://85600167 [SR-15495]
SE-0343 is approved so it's time to pull the feature out from behind the
experimental feature flag. This patch pulls it out and deprecates
passing the flag to the frontend so that we can pull it out entirely
eventually.
To help maintain source-compatibility, the presence of an `await` in
top-level code to kick the top-level code over to being a concurrent
context.
This, of course, means that in the test cases that exist today, they
will go back to behaving identically to how they did before I added all
of this because they don't have any awaits in the top-level. I'll be
adding new tests to verify the differences in behavior between swift 5,
swift 6, with and without async top level enabled in the next commit.
It's possible to create an impossible set of constraints for
instance-member stored properties of a type. For example:
@MainActor func getStatus() -> Int { /* ... */ }
@PIDActor func genPID() -> ProcessID { /* ... */ }
class Process {
@MainActor var status: Int = getStatus()
@PIDActor var pid: ProcessID = genPID()
init() {} // Problem: what is the isolation of this init?
}
We cannot satisfy the isolation of the initilizing expressions,
which demand that genStatus and genPID are run with isolation
from a non-async designated initializer, which is not possible.
This patch changes the isolation for those initializer expressions
for instance members, saying that the isolation is unspecified.
fixes rdar://84225474
The first attempt to do this was in
https://github.com/apple/swift/pull/40652
But, I implemented that as a hard source break, since the isolation
was changed in a way that an error diagnostic would be emitted.
This commit reimplements the change more gently, as a warning for
Swift 5 users.
