The crash on `SILFunction type mismatch` provides little information and
tends to be difficult to reproduce. Let's print some of the available
information and distinguish the two failure sites.
I'm not confident all required information is written down so we may
need to improve this further in the future. This version still crashes
the compiler, we may want a proper type-check to prevent this failure
with a clean diagnostic for the example used here.
rdar://53821031
Previously we were using the same set of conditions
for serializing as for swiftdoc, so excluded them.
However it's reasonable to have them in the
swiftsourceinfo.
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
Given a scenario where a public type A, conforms to an internal protocol
B, which conforms to a public protocol C. A conforms indirectly to C
through a protocol that's hidden from the clients.
This is handled in module interface by printing the indirect conformance
of A to C explicitly at the end of the swiftinterface.
We have the same problem with deserialization safety that used to hide
the internal protocols from clients, thus breaking the knowledge of the
indirect dependency. To keep the indirect conformances, let's consider
all protocols as safe and preserve their conformance information.
rdar://105241772
Disabling access control is fundamentally incompatible with
deserialization safety. Let's turn off safety automatically when in use.
This was reported by a few tests:
stdlib/Dictionary.swift
stdlib/Set.swift
stdlib/SetOperations.swift.gyb
stdlib/SwiftNativeNSBase.swift
Clients of a resilient module using opaque types don't need access to
the underlying type unless it's used in an inlinable context. Plus, the
underlying type can reference internal details which can lead to crashes
when they reference implementation-only dependencies. To clean up this
behavior, let's only serialize the underlying type if used by an
inlinable function.
rdar://105128784
The macro tests were all using "REQUIRES: OS=macosx" as a proxy for
"have the Swift Swift parser". There was an existing feature for this,
but it was just checking whether the path was passed through. Fix that
to use the same variable as in CMake.
Also remove all extraneous `-I` and `-L` to the host libs in the target
invocations.
Implementation-only dependencies may be referenced from internal decls.
When that module is imported as @testable, clients see the internal
decls and may fail accessing them if the transitive implementation-only
dependencies are not loaded.
Let's consider such transtive implementation-only dependencies as
optional for @testable imports. As such, the compiler will attempt to
load them for test targets, and won't fail if the dependency is missing.
We can make these dependencies required for non-public imports, but it
could be project breaking to do so for implementation-only dependencies.
Considering them as optional is a decent compromise.
rdar://79459263
* A multi-file scenario where one file has a normal import and the other
a testable import. In this case we still load the extra dependencies
and show diagnostics only of the testable import.
* A scenario where module A @testable imports module B, which @_exported
imports module C. In this case, non-public imports of B are loaded,
but not those of C. This is a limitation of the current implementation
and could be improved upon in the future.
A @testable import allows a client to call internal decls which may
refer to non-public dependencies. To support such a use case, load
non-public transitive dependencies of a module when it's imported
@testable from the main module.
This replaces the previous behavior where we loaded those dependencies
for any modules built for testing. This was risky as we would load more
module for any debug build, opening the door to a different behavior
between debug and release builds. In contrast, applying this logic to
@testable clients will only change the behavior of test targets.
rdar://107329303
The reason why we are doing this is that:
1. For non-copyable types, switches are always at +1 for now.
2. non-copyable enums with deinits cannot be switched upon since that would
invalidate the deinit.
So deinits on non-copyable enums are just not useful at this point since you
cannot open the enum.
Once we make it so that you can bind a non-copyable enum at +0, we will
remove this check.
I added an experimental feature MoveOnlyEnumDeinits so tests that validate the
codegen/etc will still work.
rdar://101651138
SE-0382 allows macro parameters to have default arguments. Enable these
default arguments, with the normal type checking rules. One
significant quirk to this implementation is that the actual default
argument values don't make it to the macro implementation. This is a
previously-unconsidered design problem we'll need to address.
Tracked by rdar://104043987.
Differentiate `internal` and `fileprivate` imports from
implementation-only imports at the module-wide level to offer a
different module loading strategy. The main difference is for non-public
imports from a module with testing enabled to be loaded by transitive
clients.
Ideally, we would only load transitive non-public dependencies on
testable imports of the middle module. The current module loading logic
doesn't allow for this behavior easily as a module may be first loaded
for a normal import and extra dependencies would have to be loaded on
later imports. We may want to refactor the module loading logic to allow
this if needed.
rdar://106514965
the main things still left behind the experimental flag(s) are
- move-only classes (guarded by MoveOnlyClasses feature)
- noimplicitcopy
- the _borrow operator
Specifically:
1. Fix the error message so that when we say you can't have a deinit that a
deinit can be on a noncopyable type along side a class or an actor.
2. Even though we already error on @objc enums and say they cannot be
noncopyable, we did not emit an error on the deinit saying that @objc enums
cannot have a deinit. I put in a nice to have error just to make it even
clearer.
rdar://105855978
rdar://106566054
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
Modules loaded from the resource dir are not usually rebuilt from the
swiftinterface as it would indicate a configuration problem. Lift that
behavior for SDK mismatch and still rebuild them.
This use case applies when a toolchain is used with a different SDK than
the one use to build the modules in the toolchain.
rdar://106101760
We want to ensure that the deserialization error added
for this test doesn't trigger when the moveonly type
is not used by the importing module.
part of rdar://106262652
This general test applies to all access-level. Let's precise that it
tests the scenario where a client is outside of the package to preserve
the current behavior. A new tests will check the behavior of a package
dependency for clients in package.
