Previously these used the same "major architecture" names that the
`#if os(...)` query accepts, but that can be a problem when building
for, say, both armv7 and armv7s, even if the content is "the same".
For a transition period where external build tools are involved, the
compiler will look for "arm.swiftmodule" if it fails to find
"armv7.swiftmodule" or any other 32-bit ARM architecture. No other
Apple platform architectures are affected, and AFAIK no one's using
the architecture-based layout on Linux or any other platforms.
rdar://problem/45174692
- The GenericSignatureBuilder assumed it didn't have to look in
protocol extensions to resolve member types.
- Serialization was incorrectly filtering out such typealiases when
trying to resolve a cross-module reference to one.
rdar://problem/46103190
This diagnostic needs to be adapted for swiftinterfaces too, but
meanwhile let's not have it get in the way when dealing with a
multi-architecture module that has parseable interfaces.
MyKit.framework/
Modules/
MyKit.swiftmodule/
x86_64.swiftinterface
x86_64.swiftdoc
# no x86_64.swiftmodule
This is actually two separate problems:
- 'override' wasn't getting added to initializers in deserialization
- 'override' was getting added when inheriting a 'required' initializer,
even though it's normally an error to write that
Needed for parseable interfaces.
Now that we don't store requirements in the GenericParamList, there's
no reason to use trailing records to list out the
GenericTypeParamDecls.
No functionality change.
Re-applied after fixing a bug in Serialization where the DeclContext
wasn't being set correctly for extensions with nested parameters. I
was unable to come up with a reduced test case, but the CoreStore
project in the source compatibility suite was failing without the
Serialization change, and now it isn't.
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Otherwise, we can't represent a cross-reference to generic parameters
in a parent type /when used in an extension/.
https://bugs.swift.org/browse/SR-9084
Previously, the fast path for nested types only worked when the nested
type was defined in a Swift module or a Clang module without an
overlay; this is because it was originally designed to fix circularity
issues when merging partial modules for a single target. By having a
Swift overlay module pass through requests for nested types to the
underlying Clang module, we get the fast-path behavior in more cases.
(The one case where it /won't/ kick in is if the overlay has a nested
type that shadows a nested type from the Clang module, but that's
probably pretty rare!)
BCRecordLayout currently assumes that the layout described in source
always matches the layout in the bitstream being read. Since we want
swiftdocs to be a forward-compatible format, avoid using it for
deserialization.
(In the future, we may want to augment BCRecordLayout to handle
records with more fields than expected. For now, though, this is a
sufficient change.)
The functionality change in this commit is that the control block in a
swiftdoc file is validated rather than just being ignored. Tests in
following commit.
