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
...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
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.)
In Windows Server 2016 at least, the Network Service user (the one being
used by the CI machine) is returned as Host$, which icacls doesn't
understand. Turn the name into something that icacls if we get a name
that ends with a dollar.
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
`#import` is an extension which behaves differently in different target. On
Windows, it is used to import type libraries (for COM). The options are to
either use `#include` or enable Objective-C interop. Use the former since there
is no Objective-C specific behaviour needed here.
(as described in the previous commit)
When printing an interface that has to be stable, we need to use the
module name that identifies where declarations should be searched for,
just like we do with serialization.
rdar://problem/49114811
Right now we're not being careful about 'optional' in witness tables
for parseable interfaces; we're listing the requirement as the
implementation even if the requirement is optional. As long as we
don't optimize based on that information, though, we should be okay.
We can't devirtualize through these conformances anyway, so we can get
a (probably tiny) speedup by not doing any resolution of non-type
witnesses.
rdar://problem/43824088
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".
