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 protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
There's no good reason to permit them. Conformances like Copyable and
Sendable are pervasive, so it's as though we are permitting extensions
of `Any`. Until there's a good argument in favor of such extensions,
remove the capability now.
Now that `InferredGenericSignatureRequest` creates
`StructuralRequirement`s from of the generic signature with valid source
locations, additional redundancy warnings are produced. Update tests
with the new warnings.
Specifically:
1. Fix the error message so that when we say you can't have a deinit that a
deinit can be on a noncopyable type along side a class or an actor.
2. Even though we already error on @objc enums and say they cannot be
noncopyable, we did not emit an error on the deinit saying that @objc enums
cannot have a deinit. I put in a nice to have error just to make it even
clearer.
rdar://105855978
rdar://106566054
Calling computeExtendedNominal() won't catch the case where the
extended type did not exist at extension binding time but then
appeared later, like an inferred associated type witness for
example.
When realizing a type like Foo<A>.Bar, we have to account for the
possibility that Bar is defined in a constrained extension of Foo,
and has generic requirements beyond those that Foo itself places
on 'A'.
Previously we only handled this for types referenced from the
constraint system as part of openUnboundGenericType(), so we were
allowing invalid types through in type context.
Add the right checking to applyGenericArguments() to close the
hole. Note that the old code path still exists in the constraint
solver; it is used for member accesses on metatype bases only.
Fixes <https://bugs.swift.org/browse/SR-10466>.
Do not offer a mutating fix-it if we have a mutating protocol requirement and we're assigning to it from an implicitly nonmutating setter inside a protocol extension
When there's a module with the same name as a type in a
different module, lookup will look into the type, not the module, when
resolving members. Until that behavior is fixed, add a note showing what
lookup was trying to look into, to make the behavior more clear.
Helps rdar://54770139
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
IsFirstPass is going away soon, but in the meantime, the next
patch regresses matters slightly and causes us to emit
duplicate diagnostics in more cases, so let's fix it.
Within an extension, references to other members of the extended type
are permitted without qualification. This is intended to work even
when the extended type was a nested type, although members of the
enclosing type are /not/ visible in this case. In order to implement
this, the type checker pre-checks to see if there are /any/ members
with this name and then rewrites the unqualified reference to a
qualified one, based on an unresolved TypeExpr with the name of the
enclosing type. Unfortunately, if the enclosing type is a nested type,
that isn't going to work very well---we find the correct declaration,
but fail to map it into context by virtue of not realizing where it
came from. Fix this by explicitly checking for this case.
https://bugs.swift.org/browse/SR-3847
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
