If the fix-it would remove a range that is followed by a newline and the
remaining text on the line is empty or all whitespace then remove the entire
line. This produces better results when a fix-it removes an attribute that is
written on a line by itself.
It was originally introduced as an upcoming feature, but there isn't any
precedent for using upcoming features as a way to opt-in to type checking fixes
without an associated Swift Evolution proposal. Rather than using a "feature" to
control this behavior, it would probably be better to offer a way to use
`-Werror` to upgrade these warnings to errors.
Fixes rdar://89864078, by checking if all the required vars are
immutable, and suggesting mutable variables be converted to immutable to
become nonisolated and presumably fix the isolation issue. Also suggests
'nonisolated' on var decls without storage or wrapper. Additionally,
converts existing 'nonisolated' for method suggestion to emit per-method
instead of a top level 'all', for consistency with the new diagnostic,
based on PR feedback.
The ObjC thunk already attempted to do fixup for ownership mismatches
but it derived the wrong parameter convention for the ObjC thunk itself
so this fixup did not happen. This PR makes sure we have the correct
ownership convention for the ObjC thunk so the fixup actually happens.
Furthermore, this PR relaxes the type checker so we no longer error out
on the ownership convention mismatch.
rdar://172701291
A requirement defines the maximal effects that a witness can have.
In some cases, we'd fail to properly reject such a witness with more
effects, when that witness is valid for another requirement within that
protocol. Thus, we'd hit an assertion failure in that case rather than
permitting the valid program to compile.
In a non-asserts compiler, we could end up failing to diagnose an invalid
chosen witness and crash in IRGen.
https://github.com/apple/swift/issues/73479
rdar://127669069
@objc @implementation annotated Swift methods did not check whether the
ownership conventions of the Swift function match the Obj-C(++)
declaration. A mismatch can result in use after free errors or leaks.
This PR adds some extra check for the ownership conventions and also
makes sure the imported Swift declaration is has the right parameter
ownership for `NSConusming` and `CFConsuming` annotated parameters.
rdar://168929333
Update diagnostic wording to mention both WritableKeyPath and ReferenceWritableKeyPath, include actual type in message, and refactor subscript parameter validation using a local checker for wrapped/projected and storage parameters.\n\nUpdate regression expectations accordingly.
Emit a dedicated diagnostic when an enclosing-self property wrapper subscript uses non-key-path types for the 'wrapped/projected' or 'storage' parameters, and ignore such subscripts for synthesis to avoid fallback <unknown>:0 key-path inference failures.\n\nUpdate property_wrappers_invalid.swift to verify the new direct diagnostics instead of relying on verify-ignore-unknown.\n\nResolves https://github.com/swiftlang/swift/issues/54422
Normally, an unbound reference to a generic type within its own context is automatically bound to the identity generic arguments:
```
struct G<T> {
typealias TA = G // as if you wrote G<T>
}
```
Module selectors normally disable this kind of contextual behavior; make sure that this is not an exception.
To pipe the information needed to do this through the constraint solver, we extend FunctionRefInfo to remember whether a module selector was used.
Enable the feature by default, and add an experimental feature
`DeprecateCompatMemberwiseInit` to control the deprecation behavior
which was deferred from the proposal.
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
Fix regression from 62e4979691.
An associated type can be witnessed by a type alias that is
directly declared in a protocol. Don't drop it in this case.
It seems that this didn't matter too much in the past, but
now that name lookup prefers an associated type declaration
over a type alias (which may or may not be the type witness),
we really must correctly resolve the associated type to a
type witness instead of just dropping it sometimes.
Fixes rdar://167851622.
Invite users of `@_implementationsOnly` imports from modules without
library-evolution to adopt `CheckImplementationOnly`. Use the existing warning
on the import statement. Adopting that feature reports unsafe references to
implementation-only imported types as errors and silences the warning on
the import.
Looking up serialized extensions for a nested nominal type requires
computing its mangled name, which may kick semantic requests. Ensure
we don't do this for nominals in parsed SourceFiles such that we
don't end up kicking this during extension binding.
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
Private member witnessing a public constraint should be deprecated.
Previously existing workaround is checked and compiler emits a warning
when strict access check is not passed. Test files were fixed to expect
the corresponding warning.
rdar://74904373
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
Allan Shortlidge
Aidan Hall
Aidan Hall
Aviva Ruben
Aviva
Meghana Gupta
Meghana Gupta
Hamish Knight
Gabor Horvath
Kavon Farvardin
Pavel Yaskevich
Gábor Horváth
Pavel Yaskevich
Flamki
Becca Royal-Gordon
Sam Pyankov
Alexis Laferrière
Slava Pestov
Tim Kientzle
Xi Ge
Jamie