When referencing a declaration, check whether any of the types in that
reference are unsafe. This can diagnose cases where the original
declaration either wasn't actually unsafe, or is being provided with
unsafe types via generics.
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
In this PR i worked on replacing the word accessor in diagnostics with more user-facing terminologies like setter, getter, didSet Observer, and members based on the context of the message.
in some messages i didn't need to pass DescriptiveDeclKind instead i just changed the text copy itself.
i also updated tests, so you might find it easier to check my changes this way.
Please let me know if there's something i should've done in a better way, and request changes if needed. !
i can squash my commits after reviewing getting the PR Reviewed, just to make it easier to be checked commit by commit
Resolves#55887
This diagnostic reports when two compilers that are marked as targetting
different distribution channels try to read swiftmodules produced by the
other one. For a resilient module, this error is usually silently ignored
as the reader compiler picks the swiftinterface over the swiftmodule.
It is visibile to the end user when the module is non-resilient.
For such a case, we here try to improve the diagnostic to be more
meaningful.
The new diagnostics looks like so:
```
import ChannelLib // error: the binary module for 'ChannelLib' was compiled
// for 'restricted-channel', it cannot be imported by the
// current compiler which is aligned with 'other-channel'.
// Binary module loaded from path: .../ChannelLib.swiftmodule
```
Vendors should be mindful to pick meaningful channel names
to guide users in the direction of the actual solution.
Allow `fallthrough` to appear as the last statement
in the case of a `switch` expression. We already
allowed it in other positions, this was just an
oversight.
rdar://127670432
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.
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
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
wording.
Splitting up the diagnostic into separate diagnostics based on the reference
kind is easier for me to read. The wording of the error message now puts
the problem -- crossing an isolation boundary -- at the center of the message,
and attempts to clarify how the value crosses an isolation boundary. E.g. for
the witness diagnostics, the value crosses an isolation boundary when calling
the witness through the protocol requirement in generic code.
This change does not add any additional information to the diagnostics, but it'd
be valuable to show both the source and destination isolation.
Sema's sendable checking is subsumed by the region isolation SIL pass. Now
that region isolation is always enabled under complete concurrency checking,
the code can be deleted from the actor isolation checker. Note that this
removes these diagnostics from targeted concurrency checking. I think it's
better to remove these diagnostics from targeted checking because in many
cases, they're false positive data-race reports that the programmer ultimately
won't have to address. If we want these diagnostics in targeted checking, we
should do it via region isolation.
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Degrade concrete type specialization fix to warning for macros.
As of now, SE-366 is not correctly implemented with respect to concrete,
bitwise-copyable types like `Int`. Writing `consume someInt` doesn't
actually consume the variable binding as it should, meaning code that
should be flagged as having a use-after-consume is being silently
permitted:
```swift
let someInt = 10
let y = consume someInt
print(someInt) // no error!
```
This has been a problem since Swift 5.9. Eventually we plan to fix this
issue, which means code previously doing the above would become an
error. To help people get ready for the fix, start warning people that
these consumes are actually no-ops and suggest removing them until the
intended behavior is actually enforced in the future.
resolves rdar://127081103
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
We don't yet have keypaths working correctly to allow access to
noncopyable fields, so we should raise a friendly error in Sema rather
than an error-out elsewhere vaguely.
resolves rdar://109287447
Attempting to bypass the compiler and access runtime functions directly has
a long history of breaking in hard-to-predict ways, and there's usually a better
way. Put up a warning to try to flush out misuses of runtime functions to see
if we can turn this into an error.
Previously we could end up with a
ContextualMismatch fix and a MissingConformance fix
for different elements of the `matchTypes` disjunction,
leading to an ambiguity. Instead, avoid recording
the ContextualMismatch if we're matching an
existential, and tweak the MissingConformance
failure to have a custom diagnostic for
EnumElementPattern matching.
This is done by diagnosing captures of `self` in escaping `sending` or
`@Sendable` closures inside a deinit, which almost certainly means `self`
will outlive deinit at runtime, which is a fatal error. This is a common
mistake to make when creating isolated tasks inside nonisolated deinits
to workaround the lack of synchrnous isolated deinits in Swift 6.
defining module, and diagnose redundant Sendable conformances.
We still allow re-stating inherited unchecked Sendable conformances in
subclasses because inherited Sendable conformances are surprising when
they opt out of static checking. Otherwise, warning on redundant Sendable
conformances nudges programmers toward cleaning up unnecessary retroactive
Sendable conformances over time as libraries incrementally add the
conformances directly.
