Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
In asserts builds this hits an assert that the
feature isn't enabled, and in no-asserts builds
this incorrectly allows `do` expressions to be
used with the feature disabled. Note this only
affects their use when nested in an `if`/`switch`
that is used in a binding, we correctly handled
the other cases.
rdar://121193678
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.
Most clients only want to set one of the two
parameters, split it into `setPattern` and
`setInitContext` (the latter of which now
handles calling `setBinding`).
Switch from promising a DeclContext to a
PatternBindingInitializer.
This has a couple of benefits:
- It eliminates a few places where we were force
`cast`'ing to PatternBindingInitializer.
- It improves the clarity of what's being stored,
it's not whatever the parent context of the
initializer is, it's specifically the
PatternBindingInitializer context if it exists.
rdar://121071710
Currently it uses builtin integers, which round up to the next power of 2, which is not what we want here. Instead it should use builtin vectors of uint8 and a number of elements equal to the stride in bytes.
Introduce a new expression macro that produces an value of type
`(any AnyActor)?` that describes the current actor isolation. This
isolation will be `nil` in non-isolated code, and refer to either the
actor instance of shared global actor in other cases.
This is currently behind the experimental feature flag
OptionalIsolatedParameters.
When the BitwiseCopyable experimental feature is enabled, infer types to
conform to `_BitwiseCopyable`. The `_BitwiseCopyable` inference broadly
follows the approach taken to infer `Sendable`.
(1) Special types are conformed:
- function types if trivial
- metatypes
- builtin types if trivial
(2) TheTupleType is conditionally conformed.
(3) Nominal types are conformed if:
- non-public or public+fixed-layout
- enum or struct (non-class)
- every field conforms to _BitwiseCopyable
Additionally, check that nominal types which are explicitly conformed to
`_BitwiseCopyable` satisfy the latter two conditions of (3).
For a public, non-fixed-layout type to conform to `_BitwiseCopyable`,
the user must conform the type explicitly.
Finally, verify that conformances correspond to TypeLowering's notion of
triviality to the appropriate extent:
- if a type isn't trivial, it doesn't conform to `_BitwiseCopyable`
unless it's an archetype
- if a type is trivial, it conforms to `_BitwiseCopyable` unless some
field in its layout doesn't conform to `_BitwiseCopyable`, which is
only permitted under certain circumstances (the type has generic
parameters, the type is public non-fixed-layout, the type is a
reference but has ReferenceStorage::Unmanaged, the type is a
ModuleType, etc.)
There is a small bug fix here in the identification of the catch node,
where the leading `{` of a closure was considered to be "inside" the
closure for code like
{ ... }()
causing us to assume that the call to the closure would catch the error
within the closure.
Other than that, introduce the thrown error type into the type checker's
modeling of `withoutActuallyEscaping(_:do:)`, and mirror that in the
library declaration.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
Due to the duality between the expression and declaration forms of
freestanding macros, we could end up assigning two different discriminators
to what is effectively the same freestanding macro expansion. Across
different source files, this could lead to inconsistent discriminators in
different translation units. Unify the storage of the discriminator to
avoid this issue.
Fixes rdar://116259748
There are a bunch of static `collectExistentialConformances` copied
around Sema and SILGen that are almost the same, save for whether they
want to permit missing conformances and/or check conditional
conformances.
This commit requestifies and combines all but one of these functions
into a `ModuleDecl::collectExistentialConformances`. The motivation for
this clean-up is another place that will need this procedure.
