* 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
Using an access-level on an import downgrades imported decl from public
to the import's access-level. When we can identify which decl is
problematic, name it in the note displayed on the import. This should
help understanding the effect of the import's access level on the decl
causing an error further down in the source file.
Check accessibility of all build{Partial}Block overloads and
diagnose if none of them are as accessible as type, otherwise
swift interfaces could end up with invalid result builder
declarations when type is public and all builder methods are
internal.
Resolves: rdar://104384604
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
This means properties returning noncopyable types or those
marked with `@_borrowed` can't have effects. The compiler
never accepted the latter correctly before.
The synthesized coroutine `read` calls the user-defined `get`,
but coroutines don't support `async` or `throws`.
resolves rdar://106260787
These initializers implicitly return an optional of the
nominal type, but we can't wrap move-only / noncopyable
types inside of optionals at the moment, because that
would permit copying.
resolves rdar://106120881
Create a checker for @_objcImplementation member implementations that considers all of a class’s interface and implementation decls at once. This allows us to handle several things better:
• Unimplemented requirements are now diagnosed
• Header members that can match several implementations, or implementations that could match several header members, are now diagnosed
• Tailored diagnostic when the implementation's Swift name matches the header's selector instead of its Swift name
• Recommends inserting `@objc(<selector>)` when a Swift name matches but the implicit ObjC name doesn't
• An `@objc(<selector>)` on one implementation can eliminate its requirement from being considered for other implementations, resolving ambiguities
This does unfortunately regress the diagnostics when a requirement is implemented in the wrong extension. Some sort of whole-module checking would be needed to address this problem.
Swiftmodules built by a mismatching compiler are loaded if the mismatch
is only on the last digit of the compiler version. In such a case, write
a remark directly to stderr to avoid showing this error in IDE but keep
it for debugging purposes.
rdar://105881894
Check the API of decls to ensure that imported types are only used in
decls with compatible access-level. For example, error on using a type
import as internal in a public function, but allow it in internal
functions and lower.
This change raises errors on wrongful use of types limited by an import
and offers a note pointing to the import that did limit the imported
type.
• `@objc` is now inferred on non-`final` members of @objcImplementation extensions
• Diagnostics now suggest adding `private` to ObjC helper members, not `@objc`, in line with currently proposed behavior
• Better diagnostic for members implemented in the wrong extension
Part of rdar://103150189.
We can't implement `forget` unless if we know all of the fields
in the type, so it cannot be resilient at all. We go further and
say that you can only `forget` from the same module, since that's
what the proposal currently states. If needed we can loosen that
in the future.
Currently, this is staged in as `_forget`,
as part of SE-390. It can only be used on
`self` for a move-only type within a consuming
method or accessor. There are other rules, see
Sema for the details.
A `forget self` really just consumes self and
performs memberwise destruction of its data.
Thus, the current expansion of this statement
just reuses what we inject into the end of a
deinit.
Parsing of `forget` is "contextual".
By contextual I mean that we do lookahead to
the next token and see if it's identifier-like.
If so, then we parse it as the `forget` statement.
Otherwise, we parse it as though "forget" is an
identifier as part of some expression.
This way, we won't introduce a source break for
people who wrote code that calls a forget
function.
This should make it seamless to change it from
`_forget` to `forget` in the future.
resolves rdar://105795731
@_exported can only be used on public imports, it's incompatible with
any other access level. This implementation doesn't take into account
Swift 6 mode.
