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
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
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
Otherwise we've got a problem with modules that use -parse-stdlib but
aren't the stdlib themselves. Ideally we'd /only/ print this in that
case, but we don't have that information at this point in the pipeline
and I'm not sure it would be a good idea to include it in the set of
options we pass through.
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
