Currently, the check for whether to serialize parseable interface
arguments doesn't handle the case where a supplementary output file map
is used, preferring only to check if the frontend is passed
`-emit*interface`. Instead, check if the frontend inputs and outputs
contains a parseable interface, and use that to determine if we need to
save args.
This also puts `-module-link-name` in the parseable interface arg list.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
The YAML format is the same one produced by the -dump-type-info
frontend mode.
For now this is only enabled if the -read-type-info-path frontend
flag is specified.
Progress on <rdar://problem/17528739>.
Add a staging option for enabling upcoming changes in the solver in
support of using the protocols designated in Policy.swift to guide
operator type checking.
When provided, this flag warns about implicit overrides, where a
declaration overrides another declaration but is not marked with the
‘override’ keyword. The warning can be suppressed by either providing
‘override’ or ‘@_nonoverride’.
At present, this only happens with overrides in protocols.
LLDB needs the -swift-version because the -D__swift__ macro affects
how Clang modules are built. This currently has the really odd effect
that when debugging a Swift program that is not using the very latest
Swift version, the first "po" takes several seconds, because the
module cache needs to be rebuilt.
rdar://problem/40241256
This is helpful in experimenting with constraint solver changes that
might help us remove some of these unsound options. It's not ever mean
to be enabled, but if we're able to remove the things guarded by the
option we can eventually remove the option.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
I made this change by removing the SILOption and then doing a compile, fix loop. I
purposely did not move around the code to make the refactoring really easy to
see.
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
We sometimes see expression type checking times increase dramatically
when this is enabled, and having a way to disable will make it
possible to easily do measurements to determine the cost/benefit of
having this enabled.
As a debugging aid, introduce a new frontend flag `-debug-cycles` that
will emit a debug dump whenever the request-evaluator encounters a cyclic
dependency, while otherwise allowing compilation to continue.
This work-around is no longer needed now that the full fix landed in
https://github.com/apple/swift/pull/16615. The argument is left with a warning
to help with migration between compilers with the work-around and compilers with
the full fix (see also rdar://problem/40502379).
Fixes rdar://problem/40476573.
IRGen can introduce calls to type metadata accessors for types that
should not be visible to the current translate, which can manifest in
linker errors within a module (for references to private types when
whole module optimization is disabled) or across modules (for
references to private/internal types in another module). Introduce a
new compiler flag `-emit-public-type-metadata-accessors` that emits
all type metadata accessors with public linkage, to work around the
problem in affected projects. This flag is intended to go away once we
have a proper solution.
This bug has been around in Swift "forever", but compiling the
overlays using -enable-resilience has exacerbated the problem and
caused regressions. This is a short-term fix to
rdar://problem/40229755 while we work on the correct long-term fix.
Note that I said "warnings"; we're going to be more cautious about
rollout and just make this a warning in Swift 5 mode, with /no/
diagnostics in Swift 3 and 4. Users are still free to use `@unknown
default` in these modes, and they'll get a fatal run-time error if
they don't and an unexpected case actually shows up.
rdar://problem/29324688
When running Swift from within LLDB, we need to bypass resilience since LLDB
does not support resilience yet. However, the bypass was done too early as
part of the module loader, which had the effect of disabling resilience
altogether.
We still want resilience at the SIL level so that function types lower the
same with debugger support turned on and off. Only IRGen needs to bypass
resilience, so that LLDB can calculate fragile layouts of types. Also, the
DebuggerSupport flag is not always set in the ASTContexts created by LLDB.
So replace it with a new flag that only controls this behavior and nothing
else, and make it part of IRGenOptions to make it totally clear that it only
impacts IRGen.
Together with the paired LLDB change, fixes <rdar://problem/38719739>
and <rdar://problem/38483762>.
It was only used in a few tests. Those tests now use -emit-sil instead
of -emit-silgen, with some functions marked @_transparent and a few
CHECK: lines changed now that the mandatory optimizations get to run.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
To support migration from both Swift 3 and 4, this patch
teaches the driver to pick up the right set of migration scripts
according to the given Swift version. We also pushed some placeholder script
files for migration from Swift 4. This patch also brings the migrator
up-to-date by avoiding migration if the Swift version is already 4.2.
