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
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Stop filtering outer overload choices while trying to pre-check
expression, instead have it always fetch those and use new
fix to only attempt them in diagnostic mode (unless it's min/max
situation with conditional conformances).
Associated type inference can synthesize type aliases with the same name
as a generic parameter. This is all fine since the underlying type of
the alias is the generic parameter type, however it might have been
synthesized in a constrained extension, resulting in bogus diagnostics
that depend on the order in which declarations are type checked, which
can vary between WMO and non-WMO, different batch mode settings, etc.
Instead, let's just check the generic parameter list first.
Fixes <rdar://problem/22587551>, <rdar://problem/44777661>.
For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
Extend the inputs to InheritedTypeRequest, SuperclassTypeRequest, and
EnumRawTypeRequest to also take a TypeResolutionStage, describing what
level of type checking is required. The GenericSignatureBuilder relies
only on structural information, while other clients care about the
full interface type.
Only the full interface type will be cached, and the contextual type
(if requested) will depend on that.
The verifier asserts that declarations whose interface type contains an error
are invalid, so let's just mark them invalid when we set the interface type,
instead of needlessly duplicating this logic all over the declaration checker.
This eliminates the need for an ugly and incomplete hack to suppress
noescape inference for setter arguments. It also means we stop emitting
redundant diagnostics for problems in storage types.
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
Previously, validateDecl() would check if the declaration had an
interface type and use that as an indication not to proceed.
However for functions we can only set an interface type after
checking the generic signature, so a recursive call to validateDecl()
on a function would "steal" the outer call and complete validation.
For generic types, this meant we could have a declaration with a
valid interface type but no generic signature.
Both cases were problematic, so narrow workarounds were put in
place with additional new flags. This made the code harder to
reason about.
This patch consolidates the flags and establishes new invariants:
- If validateDecl() returns and the declaration has no interface
type and the isBeingValidated() flag is not set, it means one
of the parent contexts is being validated by an outer recursive
call.
- If validateDecl() returns and the declaration has the
isBeingValidated() flag set, it may or may not have an interface
type. In this case, the declaration itself is being validated
by an outer recursive call.
- If validateDecl() returns and the declaration has an interface
type and the isBeingValidated() flag is not set, it means the
declaration and all of its parent contexts are fully validated
and ready for use.
In general, we still want name lookup to find things that have an
interface type but are not in a valid generic context, so for this
reason nominal types and associated types get an interface type as
early as possible.
Most other code only wants to see fully formed decls, so a new
hasValidSignature() method returns true iff the interface type is
set and the isBeingValidated() flag is not set.
For example, while resolving a type, we can resolve an unqualified
reference to a nominal type without a valid signature. However, when
applying generic parameters, the hasValidSignature() flag is used
to ensure we error out instead of crashing if the generic signature
has not yet been formed.
The previous patches regressed a test where we used to diagnose
(poorly) a circular associated type, like so:
associatedtype e: e
With the error "inheritance from non-protocol, non-class type 'e'".
This error went away, because we end up not setting the interface
type of the associated type early enough. Instead, we return an
ErrorType from resolveTypeInContext() and diagnose nothing.
With this patch, emit a diagnostic at the point where the ErrorType
first appears.
Also, remove the isRecursive() bit from AssociatedTypeDecl, and
remove isBeingTypeChecked() which duplicates a bit with the same
name in Decl.
Fully-qualified references to associated types in parameter lists of
constructors could result in infinite recursion and crash the compiler
when the typealias for the associated type is not defined.
Use the same approach used in normal function parameter lists of setting
IsBeingTypeChecked on the enclosing type to avoid going into an infinite
recursion here.
Resolves rdar://problem/27680407.
With the previous resolveTypeInContext() patch, a few compiler
crashers regressed with this problem, presumably because we were now
performing lookups in more contexts than before.
This is a class of problems where we would attempt a recursive
validation:
1) Generic signature validation begins for type T
2) Name lookup in type context finds a non-type declaration D nested in T
3) Generic signature validation begins for D
4) The outer generic context of D is T, but T doesn't have a generic
signature yet
The right way to break such cycles is to implement the iterative
decl checker design. However when the recursion is via name lookup,
we can try to avoid the problem in the first place by not validating
non-type declarations if the client requested a type-only lookup.
Note that there is a small semantic change here, where programs that
were previously rejected as invalid because of name clashes are
now valid. It is arguable if we want to allow stuff like this or not:
class A {
func A(a: A) {}
}
or
class Case {}
enum Foo {
case Case(Case)
}
However at the very least, the new behavior is better because it
gives us an opportunity to add a diagnostic in the right place
later. The old diagnostics were not very good, for example the
second example just yields "use of undeclared type 'Case'".
In other examples, the undeclared type diagnostic would come up
multiple times, or we would generate a cryptic "type 'A' used within
its own definition".
As far as I understand, this should not change behavior of any existing
valid code.
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.
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
The exact message is mostly immaterial at this point, but without the
change we end up recursively validating the property, marking it invalid,
and then never actually emitting a diagnostic, leaving SILGen and
Serialization to go ahead and fail.
rdar://problem/20913392
Swift SVN r30830
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
- In name lookup, if we find a decl that is already being type checked
(which only occurs on illegal code) just assume it is acceptable instead
of blowing up with an assertion checking access control that hasn't been
evaluated yet.
- In checkInheritanceClause, make sure that the we mark the decl being
resolved as being type checked when resolving the types involved. That way,
cyclic references are detected as invalid, instead of causing assertions and
other explosions.
This fixes some compiler crashers.
Swift SVN r29538
It’s real intent is to check only the generic signature of the DeclContext provided to name lookup, then enclosing contexts. Use it for functions and initializers as well, so we have uniform lookup behavior for entities that can have generic parameters.
A follow-up commit contains some minor, semi-related tweaks along with a pile of updates to the compiler crash testsuite.
Swift SVN r26654
This seems to already be working for variables in trunk, so it's just
functions that need the fix. (I'm not sure why the variables are emitting
the error twice, but I'm not going to spend time on that right now.)
rdar://problem/19715729
Swift SVN r25276
