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
It is somewhat common to use an async-let binding to run a synchronous,
void-returning function in an async context. In such cases, the
binding's type being inferred as Void is expected, and requiring
programmers to explicitly write this to suppress a warning seems like
unnecessary boilerplate. This patch changes the diagnostic logic to
exempt async-let bindings from the existing diagnostic when the inferred
type is Void.
These methods can be simplified a bunch since the returned decl is
always the input decl and we can refactor the lambdas to just return
the auxiliary variable and have the type computation in the caller.
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
Make sure we only check this if both declarations have parameter lists.
While here, clean up the logic a bit such that we just iterate over
the parameter lists.
rdar://156874925
Record when we encounter a request cycle, and enforce that the outer
step of the cycle also returns the default value. This fixes a couple
of crashers where we were ending up with conflicting values depending
on whether the request was queried from within the cycle or from
outside it.
This helps avoid producing more downstream errors. This changes
`GenericSignature::forInvalid` to produce the same signature as e.g
`<T where T == Undefined>`. This subsumes the need to introduce
conformance requirements for invertible protocols.
This adds the -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at <unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated, but by being strict by default it should make it harder to accidentally miss diagnostics.
To avoid unnecessary performance overhead, -verify-additional-file is still required to parse the expected-* directives in files other than the main file.
Filter out any duplicate notes to help cut down on the noise for
request cycle diagnostics. Some of the note locations here still aren't
great, but this at least stops us from repeating them for each
intermediate request.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
@c @implementation relies on matching the original C declaration. The
lookup for the original C declaration was doing the wrong kind of
lookup, meaning that it could only find the C declaration if it came
through a bridging header, and not through a normal module import.
Using unqualified lookup here finds the name appropriately.
Clarify the diagnostics here as well to not talk about umbrella and
bridging headers.
Fixes rdar://161909754.
Temporarily disable the checking requirements for typealias types,
and desugar the typealias since the constraint system does not
currently correctly handle type variables in the underlying type.
