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.
We had some duplicated logic between getResilienceExpansion() and
getFragileFunctionKind(). Clean this up by moving the latter into
AST, and re-implementing the former in terms of the latter.
This also fixes a crash in at least one case where these two
implementations had previously diverged.
Fixes <rdar://problem/60605117>.
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
Effectively revert #28907. The request evaluator will also catch re-entrancy here, and those cycles can be broken with NameLookupFlags::IgnoreNewExtensions.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
