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
There were two problems here:
- isUnsupportedMemberTypeReference() checked if the immediate parent type was
an unbound generic type, but did not check for the parent of the parent, etc.
- The caller of isUnsupportedMemberTypeReference() had to re-check the
various invalid conditions to determine what diagnostic to emit, and if
none of those conditions matched it would just return an ErrorType without
emitting a diagnostic.
Fix both of these by having isUnsupportedMemberTypeReference() return an
enum indicating what went wrong, and handle more cases.
Fixes <rdar://problem/67292528>.
Name lookup might find an associated type whose protocol is not in our
conforms-to list, if we have a superclass constraint and the superclass
conforms to the associated type's protocol.
We used to return an unresolved type in this case, which would result in
the constraint getting delayed forever and dropped.
While playing wack-a-mole with regressing crashers, I had to do some
refactoring to get all the tests to pass. Unfortuanately these refactorings
don't lend themselves well to being peeled off into their own commits:
- maybeAddSameTypeRequirementForNestedType() was almost identical to
concretizeNestedTypeFromConcreteParent(), except for superclasses
instead of concrete same-type constraints. I merged them together.
- We used to drop same-type constraints where the subject type was an
ErrorType, because maybeResolveEquivalenceClass() would return an
unresolved type in this case.
This violated some invariants around nested types of ArchetypeTypes,
because now it was possible for a nested type of a concrete type to
be non-concrete, if the type witness in the conformance was missing
due to an error.
Fix this by removing the ErrorType hack, and adjusting a couple of
other places to handle ErrorTypes in order to avoid regressing with
invalid code.
Fixes <rdar://problem/45216921>, <https://bugs.swift.org/browse/SR-8945>,
<https://bugs.swift.org/browse/SR-12744>.
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
In preparation for checkEnumRawValues being turned into a request, move the common diagnostics to the decl checker so they're always emitted at the right time.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
We need to make sure they don't end up as "concrete" equivalence
classes, because they behave more like unresolved ones.
Fixes rdar://problem/40009245.
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
Use the same infrastructure we have for same-type-to-concrete
constraints to check superclass constraints. Specifically,
* Track all superclass constraints; never "update" a requirement source
* Remove self-derived superclass constraints
* Pick the best superclass constraint within each connected component
of an equivalence class and use that for requirement generation.
* Diagnose conflicting superclass requirements during finalization
* Diagnose redundant superclass requirements (during finalization)
Unify the handling of the "inheritance" clauses of a generic type
parameter, associated type, or protocol, walking them in a
TypeRepr-preserving manner and adding requirements as they are
discovered. This sets the stage for providing better source-location
information [*].
This eliminates a redundant-but-different code path for protocol
"inheritance" clauses, which was using
ProtocolDecl::getInheritedProtocols() rather than looking at the
actual TypeReprs, and unifies the logic with that of associated types
and type parameters. This eliminates a near-DRY violation, sets us up
for simplifying the "inherited protocols" part of ProtocolDecl, and
sets us up better for the soon-to-be-proposed
class C { }
protocol P: C { }
[*] We still drop it, but now we have a FIXME!
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
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.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Inference of type witnesses for associated types was previously
implemented as part of value witness matching in the constraint
solver. This led to a number of serious problems, including:
- Recursion problems with the solver hunting for a type witness,
which triggers more attemts to match value witnesses...
- Arbitrarily crummy attempts to break the recursion causing
type-check failures in fun places.
- Ordering dependencies abound: different results depending on which
value witnesses were satisfied first, failures because of the order
in which we attempted to infer type witnesses, etc.
This new implementation of type witness inference uses a separate pass
that occurs whenever we're looking for any type witness, and solves
all of the type witnesses within a given conformance
simultaneously. We still look at potential value witnesses to infer
type witnesses, but we match them structurally, without invoking the
constraint solver.
There are a few caveats to this implementation:
* We're not currently able to infer type witnesses from value
witnesses that are global operators, so some tricks involving global
operators (*cough* ~> *cough*) might require some manually-specified
type witnesses. Note that the standard library doesn't include any
such cases.
* Yes, it's another kind of solver. At simple one, fortunately.
On the other hand, this implementation should be a big step forward:
* It's far more predictable, order-invariant, and non-recursive.
* The diagnostics for failures to infer type witnesses have
improved.
Fixes rdar://problem/20598513.
Swift SVN r27616
For @objc enums, raw values determine the representation values, so we have
to compute them eagerly in order for switch statements to work. Similarly,
if the enum is broken, we have to /fail/ eagerly so that we don't fall down
later on in IRGen.
rdar://problem/19775284
Swift SVN r25282
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
