This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
swift-tools-version as used by SwiftPM is an actual, parsed field with
semantic meaning. swift-compiler-version as used when generating
module interfaces is just to record what version of the compiler
generated the interface. They shouldn't have the same name.
@_dynamicReplacement(for: selfRec(x: acc:))
func selfRec_r(x: Int, acc: Int) -> Int {
if x <= 0 {
return acc
}
// Normally, this will call selfRec(x: acc:)'s implementation.
// With the option, this will call to selfRec_r(x: acc:).
return selfRec(x: x - 1, acc: acc + 1)
}
rdar://51229650
This change PCMacro and PlaygroundTransform to return an a moduleID and
fileID in addition to the source location information. The Frontend has
been changed to run PCMacro and PlaygroundTransform on all input files
instead of the main file only.
The tests have been updated to conform to these changes with an addition
of module and file ID specific tests. The Playgrounds related tests were
adjusted to make a module out of the stub interface files since those
files should not have PCMacro and PlaygroundTransform applied to them.
rdar://problem/50821146
This option no longer works but was still in the option file and help
message.
Add a temporary pass-specific option instead for debugging until this
pass has been sufficiently tested yet.
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
Mishal Shah
mishal_shah
Joe Groff
Raj Barik
Joe Groff
Jordan Rose
Arnold Schwaighofer
Chris Brough
Andrew Trick
Harlan Haskins
Rintaro Ishizaki
Slava Pestov
Brent Royal-Gordon
adrian-prantl
Adrian Prantl
swift-ci
Michael Gottesman
Michael Gottesman
eeckstein