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
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
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
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
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.
Several places in language option parsing return early after diagnosing an error when they could instead continue parsing and discover addtional errors to diagnose. Change these to set an error flag instead.
OPT_package_description_version still has an early return on the theory that, if you’re using a too-old compiler to parse a Package.swift file, you’re probably confused about the Swift compiler version you’re using and further errors may be for arguments that would be accepted by a newer compiler.
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
If we're loading a .swiftmodule from the resource dir adjacent to the compiler,
defer to the serialized loader instead of falling back. This is mainly to
support development of Swift, where one might change the module format version
but forget to recompile the standard library. If that happens, don't fall back
and silently recompile the standard library -- instead, error like we used to.
rdar://49926152
I am going to use this to ensure some end-to-end tests that do not inline from
the stdlib will work after flipping the switch and stripping ownership after
serialization.
- Fix a typo in the debug output for finding a prebuilt module
- Don't add the prebuilt module path to the dependency tracker
- Ensure we're registering the _forwarding module_'s dependencies in
cached modules, not the prebuilt module's dependencies.
- Check for the existence of a prebuilt module before doing the
is-up-to-date check (which will have failed anyway if it didn't exist).
- Test that forwarding module dependency collection works
rdar://48659199
The fix is to set the DebugCompilationDir when -gsil is used.
Otherwise no debug info is generated if the source file name does not contain a path.
rdar://problem/49796695
...by coalescing duplicates and dropping conflicts. Both cases can
happen with "expected-error 2 {{...}}": we might get multiple fix-its
providing the same new message, or one message might have diverged
into two, giving us incompatible changes.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
Don't check for all ABI symbols when building the OnoneSupport
.swiftmodule. Whether we serialize all symbols is irrelevant. They
only need to be in the dylib for ABI purposes.
Previously, the ParseableInterfaceModuleLoader relied on the assumption
that, if it returned `errc::not_supported`, it would fall through the
search paths and then move on to the SerializedModuleLoader. This did
not anticipate the possibility of a valid .swiftinterface coming later
in the search paths, which can cause issues for the standard library
which is in the resource-dir and should always be loaded from there.
Instead, make the module loading explicitly short-circuit when seeing
`errc::not_supported`, and document it.
Also add some more logging throughout `discoverLoadableModule` so we can
more easily catch issues like this in the future.
Fixes rdar://49479386
Dependencies in the SDK have their paths serialized relative to it to allow the
produced swift module to stay valid when the SDK moves. In the windows build
mixed slashes were coming through in these paths and breaking the check for
whether a dependency was in the SDK or not.
This patch ensures both paths are using native path separators prior to the
comparison to hopefuly fix the Windows build.
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
We previously added dependencies to the tracker inline while validating a cached
module's dependencies were up to date. If one of its dependencies ended up being
out of date though, we shouldn't have added the previous dependencies, as that
means the dependency list itself was also out of date.
This patch changes the behavior to only add the module's dependencies once we've
verified they're all up to date.
This patch modifies ParseableInterfaceBuilder::CollectDepsForSerialization to
avoid serializing dependencies from the runtime resource path into the
swiftmodules generated from .swiftinterface files. This means the module cache
should now be relocatable across machines.
It also modifies ParseableInterfaceModuleLoader to never add any dependencies
from the module cache and prebuilt cache to the dependency tracker (in addition
to the existing behaviour of not serializing them in the generated
swiftmodules). As a result, CollectDepsForSerialization no longer checks if the
dependencies it is given come from the cache as they are provided by the
dependency tracker. It now asserts that's the case instead.
