These are all tests that would otherwise fail if the expression type
checker support for Swift 3 is removed.
I've moved some of the code from deleted Migrator tests into new
Constraints tests that verify that we do not support the constructs.
Rather than deferring to the heavyweight validateDeclForNameLookup()
to perform the “get overridden decls” operation, perform a much more
minimal validation that only looks for exact matches when the ‘override’
modifier is present.
The more-extensive checking (e.g., that one didn’t forget an override
modifier) is only performed as part of the “full” type checking of
a declaration, which will typically only be done within the same source
file as the declaration. The intent here is to reduce the amount of
work performed to check overrides cross-file, and limit the dependencies
of the “get overridden decls” operation.
AnyHashable.swift.gyb is by far the longest test in debug builds of the test suite. Cut it dramatically shorter by reducing the number of equivalence classes checked in “containing classes from the <foo> hierarchy” tests from 16 down to 3.
(It seems to me the extra test cases didn’t actually test any additional functionality.)
Currently when call involving prefix/postfix operator is formed we
don't wrap argument in implicit parens (like we do with other calls)
when user didn't provide any explicitly, this is bad because
argument-to-parameter matcher requires multiple special cases to handle
such behavior, so let's start wrapping arguments in implicit parens instead.
Resolves: rdar://problem/40722855
Resolves: [SR-7840](https://bugs.swift.org/browse/SR-7840)
None of these failed naturally based on the limits of the "too
complex" heuristic and several were relatively closer to the time-out
threshold used in the test RUN line.
Increasing the complexity will ensure that we don't see spurious
failures on builders or on local machines.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
This is enough to let the test case in rdar://problem/40899824 pass,
and any callers of this function already need to be able to handle a
nullptr result. There's a lot more work to do in this area, but it's
nice to get the simple things working again.
Because we've changed how conformances represent associated types
since Swift 4.2 branched, the error described there no longer occurs.
But we still want to make sure we don't regress.
https://bugs.swift.org/browse/SR-7337
Fix Hashable conformance of standard integer types so that the number of bits they feed into hasher is exactly Self.bitWidth.
This was intended to be part of SE-0206. However, it would have introduced additional issues with AnyHashable. The custom AnyHashable representations introduced in the previous commit unify hashing for numeric types, eliminating the problem.
AnyHashable has numerous edge cases where two AnyHashable values compare equal but produce different hashes. This breaks Set and Dictionary invariants and can cause unexpected behavior and/or traps. This change overhauls AnyHashable's implementation to fix these edge cases, hopefully without introducing new issues.
- Fix transitivity of ==. Previously, comparisons involving AnyHashable values with Objective-C provenance were handled specially, breaking Equatable:
let a = (42 as Int as AnyHashable)
let b = (42 as NSNumber as AnyHashable)
let c = (42 as Double as AnyHashable)
a == b // true
b == c // true
a == c // was false(!), now true
let d = ("foo" as AnyHashable)
let e = ("foo" as NSString as AnyHashable)
let f = ("foo" as NSString as NSAttributedStringKey as AnyHashable)
d == e // true
e == f // true
d == f // was false(!), now true
- Fix Hashable conformance for numeric types boxed into AnyHashable:
b == c // true
b.hashValue == c.hashValue // was false(!), now true
Fixing this required adding a custom AnyHashable box for all standard integer and floating point types. The custom box was needed to ensure that two AnyHashables containing the same number compare equal and hash the same way, no matter what their original type was. (This behavior is required to ensure consistency with NSNumber, which has not been preserving types since SE-0170.
- Add custom AnyHashable representations for Arrays, Sets and Dictionaries, so that when they contain numeric types, they hash correctly under the new rules above.
- Remove AnyHashable._usedCustomRepresentation. The provenance of a value should not affect its behavior.
- Allow AnyHashable values to be downcasted into compatible types more often.
- Forward _rawHashValue(seed:) to AnyHashable box. This fixes AnyHashable hashing for types that customize single-shot hashing.
https://bugs.swift.org/browse/SR-7496
rdar://problem/39648819
When we're trying to diagnose something, it's a bad look if we crash
instead. This changes the bad-associated-type recovery path to not require that
the conditional requirements have been computed, and instead detects that as a
possible error.
Fixes https://bugs.swift.org/browse/SR-8033.
This doesn't fix the fundamental problem of correctly handling such cases, but
it is better than the "error message" that occurred previously:
Assertion failed: ((bool)typeSig == (bool)extensionSig && "unexpected generic-ness mismatch on conformance").
Fixes the crash rdar://problem/41281406 (that in
https://bugs.swift.org/browse/SR-6569 (rdar://problem/36068136)),
https://bugs.swift.org/browse/SR-8019 (rdar://problem/41216423) and
https://bugs.swift.org/browse/SR-7989 (rdar://problem/41126254).
This will also preserve @escaping and @autoclosure, which were previously
dropped. This could lead to mismatches between expected and actual
canonical types for serialization cross-references.
https://bugs.swift.org/browse/SR-8045, likely others
Cross-references are identified by their containing module, with the
assumption that two modules will never have the same name. However, an
overlay has the same name as its underlying Clang module, which means
that there can be two declarations with the same name, the same type,
and the same module name. This is the underlying cause of the
'UIEdgeInsetsZero' problem, but it also affects the CloudKit overlay.
By tracking a bit that just says "this came from Clang", we're able
to resolve otherwise ambiguous cross-references.
(Why didn't we do it this way all along? Because if a declaration
moves from Clang to Swift or vice versa, that would break the
cross-reference. But that's only interesting if the swiftmodule format
is meant to be persistent across changing dependencies, and it looks
like we're moving away from that anyway. It's also a little weird for
SerializedModuleLoader to have special cases for Clang, but this isn't
the first.)
Note that I'm not reverting the UIEdgeInsetsZero workaround here; the
end state will have that coming just from UIKit as originally
described.
rdar://problem/40839486
This was originally commited in
3d32e89e33, and then backed out in
c40fd3966c due to concern over
behavioral changes.
This version avoids the optimization when there are any optional types
involved in the signatures of the functions.
For these cases, compareDeclarations can return the wrong order at the
moment.
I have another PR in the works that attempts to begin unraveling some
of the issues around fixing the overload comparisons.
