Pre-macro-expansion conformances are introduced at the point where an
attached extension macro is attached to a particular nominal type, and
can imply other conformances. Once the macro is expanded, they are
expected to be replaced by the real conformance from the extension
produced by the macro. This includes any other conformances that are
implied by that conformances. Ensure that the real conformance---and
every conformances it implies---are considered "better" than the
pre-expansion conformances.
Fixes a bug where we would pick the wrong (pre-expansion)
conformances, which would then fail to get fully type-checked prior to
serialization. This could accept invalid code that then crashed the
compiler, as in rdar://112916159.
Fix two inter-related issues with extension macros that provide
conformances to a protocol, the combined effect of which is that one
cannot meaningfully provide extension macros that implement
conformances to a protocol like Equatable or Hashable that also
supports auto-synthesis.
The first issue involves name lookup of operators provided by macro
expansions. The logic for performing qualified lookup in addition to
unqualified lookup (for operators) did not account for extension
macros in the same manner as it did for member macros, so we would not
find a macro-produced operator (such as operator==) in witness
matching.
The second issue is more fundamental, which is that the conformance
lookup table would create `NormalProtocolConformance` instances for
pre-macro-expansion conformance entries, even though these should
always have been superseded by explicit conformances within the macro
expansion buffers. The end result is that we could end up with two
`NormalProtocolConformance` records for the same conformance. Some
code was taught to ignore the pre-expansion placeholder conformances,
other code was not. Instead, we now refuse to create a
`NormalProtocolConformance` for the pre-expansion entries, and remove
all of the special-case checks for this, so we always using the
superseding explicit conformances produced by the macro expansions (or
error if the macros don't produce them).
Fixes rdar://113994346 / https://github.com/apple/swift/issues/66348
Introduce `AvailableDuringLoweringDeclFilter` which can be composed with
`OptionalTransformRange` to implement iterators that filter out unavailable
decls.
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.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
* 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
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.
Stored properties are only allowed in the extension implementing the class's main interface, not its categories. This also means banning `@objc final`, which is unenforceable anyway when ObjC subclasses are allowed, and therefore allowing `@objc let` and `@objc static` properties to be overridden if they're declared in objcImplementations.
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
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.
Querying the context for whether it is an async context is the easiest
way to detect if the context is async. Many decl contexts can be checked
at any point, but AbstractClosureExpr contexts must have been
typechecked. If this is called on an AbstractClosureExpr before the
types have been assigned, it may either crash or do bad things.
Many, many, many types in the Swift compiler are intended to only be allocated in the ASTContext. We have previously implemented this by writing several `operator new` and `operator delete` implementations into these types. Factor those out into a new base class instead.
If a conformance is found in an imported module as well as the current module,
and one of the two conformances is conditionally unavailable on the current
deployment target, pick the one that is always available.
Fixes <rdar://problem/78633800>.
LookupAllConformancesInContextRequest caches the results of performing
lookup of all of the conformances ascribed to a given iterable
declaration context. However, it was only used in a small number of
places, with most clients using a different API
(`getLocalConformances()`) that does not provide
caching, cycle detection, or dependency tracking.
Sink LookupAllConformancesInContextRequest lower in the stack, and
reimplement `getLocalConformances()` on top of it. This ensures that
all of the various queries go through the cached request and get the
benefits of the request-evaluator infrastructure.
Introduce an "all members" request to compute all of the members of a
given iterable declaration context in stable order. This builds on ABI
members so that it will also include, e.g., type aliases synthesized
for associated types.
The "semantic members" query produces the list of members that can
affect the ABI, e.g., of classes. It does not produce the complete
list of members suitable for semantic queries.
This attribute allows to define a pre-specialized entry point of a
generic function in a library.
The following definition provides a pre-specialized entry point for
`genericFunc(_:)` for the parameter type `Int` that clients of the
library can call.
```
@_specialize(exported: true, where T == Int)
public func genericFunc<T>(_ t: T) { ... }
```
Pre-specializations of internal `@inlinable` functions are allowed.
```
@usableFromInline
internal struct GenericThing<T> {
@_specialize(exported: true, where T == Int)
@inlinable
internal func genericMethod(_ t: T) {
}
}
```
There is syntax to pre-specialize a method from a different module.
```
import ModuleDefiningGenericFunc
@_specialize(exported: true, target: genericFunc(_:), where T == Double)
func prespecialize_genericFunc(_ t: T) { fatalError("dont call") }
```
Specially marked extensions allow for pre-specialization of internal
methods accross module boundries (respecting `@inlinable` and
`@usableFromInline`).
```
import ModuleDefiningGenericThing
public struct Something {}
@_specializeExtension
extension GenericThing {
@_specialize(exported: true, target: genericMethod(_:), where T == Something)
func prespecialize_genericMethod(_ t: T) { fatalError("dont call") }
}
```
rdar://64993425
Provide an accessor for retrieving the parsed members, generalizing
`ParseMembersRequest` so it can provide the parsed members for
deserialized/synthesized declarations as well. This is the counterpart
to the recently-generalized `getSemanticMembers()`; together, these
should suffice for most (all?) clients of `getMembers()`.
Generalize `ClassDecl::getEmittedMembers()` to operate on an
`IterableDeclContext`, so that it can be for other nominal types,
extensions, etc. Rename to `getSemanticMembers()` to indicate that
these are all of the members that are semantically part of that
context.
Clean up the implementation slightly so it only forces type checking
for the conformances within that particular context (using
`getLocalConformances()`) and doesn't need to list out each of the
protocols it cares about.
Re-implement operator and precedencegroup decl
lookup to use `namelookup::getAllImports` and
existing decl shadowing logic. This allows us to
find operator decls through `@_exported` imports,
prefer operator decls defined in the same module
over imported decls, and fixes a couple of other
subtle issues.
Because this new implementation is technically
source breaking, as we can find multiple results
where we used to only find one result, it's placed
behind the new Frontend flag
`-enable-new-operator-lookup` (with the aim of
enabling it by default when we get a new language
mode).
However the new logic will always be used if the
result is unambiguous. This means that e.g
`@_exported` operators will be instantly available
as long as there's only one candidate. If multiple
candidates are found, we fall back to the old
logic.
Resolves SR-12132.
Resolves rdar://59198796.
