With a few modifications:
- Changing computed get-only properties into 'let's breaks resilience in other ways we need to fix independent of key path resilience
- Fix the tests not to ask for impossible lib-before--client-after compatibility for changes that add API
Fix ASTVerifier error for end location of 'IfConfigDecl'.
Previously, for:
```
#if
// something
<COMPLETE>
```
End location of the dummy body of 'TopLevelCodeDecl' was at the eof, but the
end loc of the 'IfConfigDecl' was at the code-completion token. That
caused the ASTVerifier error "invalid IfConfigStmt end location".
https://bugs.swift.org/browse/SR-2364
rdar://problem/41217187
One expression in the new hashing implementation is going exponential,
accounting for a huge amount of type-checking type. Add (admittedly ugly)
“as UInt64” annotations to greatly reduce the time to type-check this
expression.
*Ahem* type-checking time for the standard library goes from 24s->14s with
this change. Added a type-checker “slow” performance test and captured
the problem in rdar://problem/42672946.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
Arnold fixed this by re-computing the insert position in
getSpecializedConformance(), with
https://github.com/apple/swift/pull/17904.
Fixes rdar://problem/35797159.
When looking for a representative superclass constraint, take into
account other same-type constraints by comparing against the resolved
superclass constraint type rather than the type as spelled.
Fixes SR-8179 / rdar://problem/41851224.
This makes update_checkout into a true python module that we can add nosetests
for, readme, and also split up without issue into multiple small files.
I also added a small stub test directory and support for running tests for
update_checkout during validation-testing. So once we add some tests, everything
is setup correctly in terms of the swift build for testing purposes.
This builds on initial commit which added `RelabelArguments` fix
to the solver that only supported `missingLabels` at that moment,
but now it supports all three posibilities - missing/extraneous and
incorrect labels.
* Make _sanityCheck internal
* Make _debugPrecondition internal
* Make Optional._unsafelyUnwrappedUnchecked internal.
* Make _precondition internal
* Switch Foundation _sanityChecks to assertions
* Update file check tests
* Remove one more _debugPrecondition
* Update Optimization-with-check tests
Unresolved types are formed in a few specific places within the type
checker's recovery path; don't let them bleed into the substitution
logic. Fixes rdar://problem/42448618.
This is how we originally controlled whether or not we printed out ownership
annotations when we printed SIL. Since then, I have changed (a few months ago I
believe) the ownership model eliminator to know how to eliminate these
annotations from the SIL itself. So this hack can be removed.
As an additional benefit, this will let me rename -enable-sil-ownership to
-enable-sil-ownership-verifier. This will I hope eliminate confusion around this
option in the short term while I am preparing to work on semantic sil again.
rdar://42509812
Although backtick is a kind of trivia piece, Token::getCommentRange doesn't
take it into account. Invalid Token::getCommentRange used to cause
compiler crash.
rdar://problem/42492793
https://bugs.swift.org/browse/SR-8315
Replace LoggingRangeReplaceableCollection variants with typealiases
Replace LoggingMutableCollection variants with typealiases.
Collapse BufferAccessLoggingMutableCollection variants into typealiases
Turn LoggingRandomAccessCollection into a typealias
Turn LoggingBidirectionalCollection into a typealias
SE-0213 improved cases like that but we still have problem with operator
overloads, so just need to make this a bit more complicated to reproduce again.
Resolves: rdar://problem/42304000
...unless the argument is an `Any?`, in which case we prefer `f(_: Any?)`.
This change also results in our selecting f<T>(_: T) over f(_:
Any). Coercing with 'as Any' makes it possible to explicitly select
the Any overload. Previously there was no way to select the generic
overload.
It's possible that the conforming type is equal to the generic
conformance type, but some of the substitutions replace an
abstract conformance with a concrete one.
In this case we cannot collapse away the specialized conformance,
because we lose information that way.
Fixes <rdar://problem/40164371>.
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
A constraint like `Parameter == SomethingConcrete` means references to
`Parameter` in that context behave like `SomethingConcrete`, including for name
resolution. Handling the parameter as just a parameter type means that it won't
find any non-protocol nested types (i.e. things other than associated types and
protocol typealiases are invisible).
Fixes rdar://problem/42136457 and SR-8240.
to be stable.
We currently will stop visiting the elements of a disjunction under
certain circumstances once we have found a solution. The result we get
is inherently dependent on the order in which we determine to visit
the disjunctions themselves (in addition to the elements of the
disjunction).
This change makes the order in which we visit disjunctions
stable. Future commits will create a stable ordering for the elements
of disjunctions. Once we also have that stable ordering in place we
can in theory short circuit more often as part of changing the way in
which we decide what the "best" solution is to a system.
This results in an expression in
validation-test/stdlib/AnyHashable.swift.gyb no longer being able to
typecheck in a reasonable amount of time, so I had to tweak that
expression.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
While trying to diagnose the problem with previously type-checked
sub-expression, use its type-checked variant as a source of type
information, instead of transferring from its original constraint system,
because if expression was type-checked successfully it would
have all of the required information in AST, and that doesn't
rely on associated constraint system being present.
Resolves: rdar://problem/42056741
On some platforms, when a new process is started, ARC’s autoreleased return value optimization is expected to fail the first time it is used in each linked dylib. StdlibUnittest takes care of warming up ARC for the stdlib (libswiftCore.dylib), but for Dictionary.swift, we also need to do it for Foundation, or there will be spurious leaks reported for tests immediately following a crash test.
Add the necessary dummy operations to setUp, and re-add the crash tests that were removed in #17862. (As separate tests this time, so they don’t hide leaks in non-crashing test parts.)
