* [Diagnostics] Update 'does not override' diagnostic message to include protocol context as well
* [Sema] Check whether the override context is a class or a protocol for diagnostic purposes
* [Test] Update tests with new diagnostic message for overrides in protocol context
* [Sema] Adjust diagnostic for overrides in structs and enums to use the existing 'override_nonclass_decl' diagnostic
* [Diagnostic] Fix diagnostic when checking conformance for IUO of generic parameter
Prints TypeRepr in diagnostic if possible to throw
accurate diagnostic for IUO conformance checking
Fixes [rdar://problem/64953106]. Fixes SR-13119
* Nested name lookup tests update
Name lookup will see the innermost name anyway and
preferred over fully qualified name. Hence the test
cases are also updated.
* Replaced a letter in test case that inadvertently got added
* Code format, corrections and better comments
This commit includes better comments for easy
understanding, formatted the bug fix code with
clang-format and fixes wrong variables inadvertently
introduced.
* [Test] Update type in struct codable test
This commit changes diagnostic type from error type
to Int. Although this diagnostic updated is incorrect, this will
be resolved when 32371 gets pulled.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
We should allow an associated type's default to reference the
same associated type with a base other than 'Self'.
Note that it now becomes easier to defeat this check, but it
was never air-tight anyway -- for example, you could have a
cycle of length two if each associated type's default was the
other associated type.
This is fine, because this check is purely 'cosmetic'; nothing
goes really wrong if you have a cycle here, except that the
diagnostic shifts from the declaration of the protocol to the
conforming type.
Fixes <rdar://problem/62355224>.
In `ConstraintGenerator::visitDeclRefExpr` instead of using
`getInterfaceType()` for unknown type and later mapping it into
context, let's use `getType()` which does that interally, that
allows to detect presence of error types in resulting type and
abort constraint generation.
If the setter conflict occurs in a deserialized declaration, the parent
pattern binding can be NULL. Guard the fixit on the existence of the
pattern binding so
1) we don't crash
2) we don't try to emit a fixit in otherwise extremely broken code
rdar://56558082
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>.
When a Swift declaration witnesses an ObjC protocol requirement, its error convention needs to
match the requirement. Furthermore, if there are different protocol requirements that the
Swift method can witness, with different error conventions, we need to bail out because we
can't simultaneously match all of them. Fixes rdar://problem/59496036 | SR-12201.
* [Diagnostics] Emit a warning when an immutable decodable property has an initial value
* [Sema] Use Decl::diagnose instead of Diags.diagnose
* [AST] Remove property name from 'decodable_property_will_not_be_decoded' diagnostic
* [Test] Update tests
* [Test] Update existing codable tests
* [Typechecker] Allow enum cases without payload to witness a static get-only property with Self type protocol requirement
* [SIL] Add support for payload cases as well
* [SILGen] Clean up comment
* [Typechecker] Re-enable some previously disabled witness matching code
Also properly handle the matching in some cases
* [Test] Update typechecker tests with payload enum test cases
* [Test] Update SILGen test
* [SIL] Add two FIXME's to address soon
* [SIL] Emit the enum case constructor unconditionally when an enum case is used as a witness
Also, tweak SILDeclRef::getLinkage to update the 'limit' to 'OnDemand' if we have an enum declaration
* [SILGen] Properly handle a enum witness in addMethodImplementation
Also remove a FIXME and code added to workaround the original bug
* [TBDGen] Handle enum case witness
* [Typechecker] Fix conflicts
* [Test] Fix tests
* [AST] Fix indentation in diagnostics def file
Make the message within 80 columns width
Improve diagnostic for read-only properties
Improve diagnostic for read-only properties
Improve diagnostic for read-only properties
The semantic checks for CodingKeys are being duplicated across the value witness synthesis code paths. Just synthesize a CodingKeys enum and let validateCodingKeysEnum do the heavy lifting when we actually need to go emit diagnostics.
Swift classes cannot meaningfully conform to NSObjectProtocol.
Inheriting from NSObject is the appropriate fix, so suggest that.
Fixes rdar://problem/32543753.
This breaks source compatibility a little bit more than we'd like, so
reverting it for now.
Fixes <rdar://problem/57213598>.
This reverts commit 04fbcc0149.
Previously we did this as a last resort if inference fails. The new
behavior is technically source-breaking, but I suspect nobody
relied on the old behavior.
This can help avoid cycles by eliminating some unnecessary validation work.
Fixes <https://bugs.swift.org/browse/SR-11407>, <rdar://problem/54979757>.
If a protocol requirement has a type that's a nested member
type of another member type, eg,
protocol P {
associatedtype A : Q
func f(_: A.B)
}
Then we don't actually want to use 'f()' to infer the witness
for 'A'. By avoiding doing so, we eliminate some cycles which
can allow some programs to type check that didn't before.
* [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
