This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
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.
The initial version of the debugger testing transform instruments
assignments in a way that allows the debugger to sanity-check its
expression evaluator.
Given an assignment expression of the form:
```
a = b
```
The transform rewrites the relevant bits of the AST to look like this:
```
{ () -> () in
a = b
checkExpect("a", stringForPrintObject(a))
}()
```
The purpose of the rewrite is to make it easier to exercise the
debugger's expression evaluator in new contexts. This can be automated
by having the debugger set a breakpoint on checkExpect, running `expr
$Varname`, and comparing the result to the expected value generated by
the runtime.
While the initial version of this testing transform only supports
instrumenting assignments, it should be simple to teach it to do more
interesting rewrites.
There's a driver script available in SWIFT_BIN_DIR/lldb-check-expect to
simplfiy the process of launching and testing instrumented programs.
rdar://36032055
