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.)
Removing crash tests fixed optimized test runs, but exposed an issue in unoptimized i386 simulator tests.
Disable the two affected tests until we plug all their holes.
Crashes somehow interfere with object counters in optimized tests, breaking the tests immediately following a crash test.
Remove getObjects:andKeys:count: crash tests for now.
rdar://problem/41871587
Turns out it's needed for normal builtins that can appear in inlinable
functions, including Objective-C's @available. Clang always links it
unconditionally, so so should Swift.
Note that this does mean you have to build compiler_rt to get a
successful test run on Apple platforms. That was always true if you
wanted the sanitizer tests to work, though.
rdar://problem/41911599
Moved `lit` test that runs unit tests for benchmark scripts from `validation-test/Python` to `test/benchmark` directory. Run the tests for benchmark infrustructure with single lit invocation:
````
swift-source$ ./llvm/utils/lit/lit.py -sv ${SWIFT_BUILD_DIR}/test-macosx-x86_64/benchmark
````
Documented the invocation of benchmark infrastructure tests in README.md
