Make it clear the issue is the transfer of
control flow out of the `if`/`switch` expression.
Technically things like `break` and `continue` are
allowed, as long as they are not jumping out of
the expression.
Specifically:
I changed the main error message to focus on the closure and that the closure
is being accessed concurrently.
If we find that we captured a value that is the actual isolation source, we
emit that the capture is actually actor isolated.
If the captured value is in the same region as the isolated value but is not
isolated, we instead say that the value is accessible from *-isolated code or
code within the current task.
If we find multiple captures and we do not which is the actual value that was
in the same region before we formed the partial apply, we just emit a note on
the captures saying that the closure captures the value.
I changed the diagnostics from using the phrase "task-isolated" to use some
variant of accessible to code in the current task.
The idea is that in all situations we provide a breadcrumb that the user can
start investigating rather than just saying that the closure is "task-isolated".
From a preconcurrency perspective, I made it so that we apply the preconcurrency
behavior of all of the captures. This means that if one of the captures is
preconcurrency, we apply the preconcurrency restriction to the closure. This is
one step towards making it so that preconcurrency applies at the region level...
we just are not completely there yet.
rdar://133798044
`@unknown default` in switch statements are required for resilient enums since they
might be modified with new fields in the future and modules defining the enums are
generally not built together with the consuming modules.
However, if the modules are in the same package, they are required to be built together,
thus the requirement for `@unknown default` can be skipped. This PR removes the need for
that, enabling less boilerplate. Note this change only impacts typecheck and not SIL gen.
Resolves rdar://130015149.
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
When `MemberImportVisibility` is enabled, if the import that would bring a
member declaration into scope is missing it is diagnosed as an error. The
existing resilience diagnostics that would also diagnose the same problem in
contexts that are visible in the module interface are therefore superflous with
the feature enabled.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Previously, missing return diagnostics for unreachable subscripts
differed from the treatment unreachable functions received, leading to
inconsistent diagnostic behavior. This change removes the responsibility
for handling the relevant diagnostics from the AST code, in favor of the
diagnostics implemented via the SIL optimizer. Additionally, where the
AST-generation code would previously have diagnosed a missing return for
an implicit empty getter, it will now admit as valid, deferring the
missing return diagnostics to the later SIL passes.
