I thought it would be useful to allow some uses of a module to be
'@_implementationOnly' and others to not be in case someone wanted to
change from one to the other gradually, but it turns out that if
you're trying to /make/ an import implementation-only, you want to
know everywhere you used it.
rdar://problem/50748157
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
Try a little harder to avoid printing empty extensions by seeing if
any of the inherited protocols are actually going to be printed.
Previously this just made things a little prettier, but with
implementation-only imports it's a correctness issue, since there may
be extensions of implementation-only types that do in fact conform to
non-public protocols.
rdar://problem/50748072
Otherwise, we can synthesize an extension that's extending a type
that's unavailable on a particular platform, or that conforms to a
protocol that hasn't been introduced on the minimum deployment target.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
Dependency tracking for cached compiled modules (compiled from
swiftinterfaces) can lead to a high percentage of the module being
SDK-relative paths when -track-system-dependencies is on. Cut down on
this by storing directory names in a separate record that gets
referenced from each file dependency. (Since a lot of per-file
dependencies are header files in a common directory, this is a win.)
We can do something more clever in the future, but this is a
reasonable start for, say, the overlays.
rdar://problem/50449802
...since they're part of the run-time representation. Not having this
meant that someone compiling against an interface would miscompile
uses of @objc enums defined in that interface!
rdar://problem/50410541
This test was overfitting what it was trying to test, causing different
targets (and even different assert configurations) to fail to match.
Instead, make this an executable test and ensure that round-tripping
through setting and getting behaves as expected.
Fixes rdar://46486517
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
Module interfaces don't yet carry enough information to correctly
describe the binary interface of a module compiled without
-enable-library-evolution, but we don't want to make this an error
because that would make it harder to work towards getting it in the
future.
If the project ever drops Swift 4 mode or Swift 4.2 mode, that would
break modules using those modes in their interface, so put an
unsilenceable warning in for using those modes to nudge interface
emitters to Swift 5.
rdar://problem/47792595
Although the default cache location separates by platform, a
/combined/ cache is still an interesting idea, and in that case we
need to use the full platform names.
Otherwise the overlays won't be force-loaded when you import them.
(This feature could possibly be scoped back at this point, but it's
not something that should be changed just by using module interfaces!)
Previously, we wouldn't escape `Type` and `Protocol` at all in the
ASTPrinter, which lead to unfortunate build failures while compiling an
interface.
Instead, make sure we escape them whenever we print a name that's a type
member. Except for methods, which are erroneously allowed to be called
`Type` and `Protocol`.
rdar://49858651
If an IBOutlet property is public private(set), it's interface only has a
getter. Consuming this interface was triggering a diagnostic that IBOutlet
properties must be mutable. This patch bypasses this check for module
interfaces.
Resolves rdar://problem/49856177
Also:
- additionally require the containing and overridden initializers are
designated, as that's the only case in which we should produce the '= super'
syntax in module interfaces
- Add notes to point out the locations of the overriden initializer when it's
not designated, and the corresponding parameter in that initializer when it
doesn't have a default argument to inherit.
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
