Works around an oddity of the associated type inference when the
potential witness is generic and returns (e.g.) Self.
Associated type inference needs to move off of archetypes for the
implementation to become sane. For now, this eliminates a crash.
Fixes rdar://problem/43591024.
I stopped trying to guess and actually tested them all, including the
Apple-internal tool I keep breaking. As a bonus, the RUN lines in
validation-test/Reflection/ go back to being simple.
rdar://problem/44154961
The last attempted fix relied on the assumption that lit was emulating shell
glob-expansion semantics, which it turns out it does not: lit looks at any 'cd'
command on a RUN line and then applies the specified directory as an absolute
prefix when resolving any subsequent non-absolute globs on the command line.
I.e. it will interpret the second line of:
RUN: touch /tmp/foo{1,2,3}.swift
RUN: cd /tmp && echo foo*.swift
as
RUN: cd /tmp && echo /tmp/foo1.swift /tmp/foo2.swift /tmp/foo3.swift
whereas sh interprets it as (and I wrote the last attempt relying on):
RUN: cd /tmp && echo foo1.swift foo2.swift foo3.swift
This new attempt therefore bypasses lit entirely and just delegates to sh.
While it might not be the most tasteful choice, it does what we want and in the
process lets us use loops to construct our testcase.
Copy %target-swift-reflection-test into %t instead of using a hard
link. The problem with hard links is that they can be overwritten when
the test fails, which would then truncate the original executable to
an empty file!
- Hard-link %target-swift-reflection-test into %t/ for %target-run
implementations that copy executables, like remote-run.
- Use DYLD_LIBRARY_PATH to undo that for %target-run implementations
that run the executable in place (host and simulators)
rdar://problem/43809613
* Move logic to ensure that r-value type var would get r-value type to `PotentialBindings`;
* Strip uncessary parens directly when creating `PotentialBinding`;
* Check if the binding is viable before inclusion in the set, instead of filtering it later;
* Assert that bindings don't have types with errors included in the set.
utils/remote-run will only run things in %t.
An Apple-internal tool doesn't follow symlinks.
Normal macOS and simulator runs find the support libraries relative to
the binary.
I'm not sure what to do yet, but for now let's unbreak the
Apple-internal bots I broke in 01a0de2.
We were building the following constraint, where $member and
$input are type variables and 'result' is a concrete type:
- Conversion($member, $input -> result)
When $member was fixed to a function type of arbitrary
arity, this would simplify to a conversion between $member's
result type and 'result'.
Instead, express this using the newly-added FunctionResult
constraint:
- FunctionResult($member, $result)
- Conversion($result, result)
I wasn't expecting this to change diagnostics, but it looks
like it did; I'm not going to bother investigating why,
because Pavel is going to rewrite contextual diagnostics soon
anyway. All but one are clear improvements.
Fixes <rdar://41416346> and <rdar://41416647>, two cases where
diagnostics regressed from -swift-version 3 to -swift-version 4.
* Obsolete ModifierSlice typealiases in 5.0
* Obsolete *Indexable in 5.0
* Obsolete IteratorOverOne/EmptyIterator in 5.0
* Obsolete lazy typealiases in 5.0
* Drop .characters from tests
* Obsolete old literal protocols in 5.0
* Obsolete Range conversion helpers in 5.0
* Obsolete IndexDistance helpers in 5.0
* Obsolete Unsafe compat helpers in 5.0
* Obsolete flatMap compatibility helper in 5.0
* Obsolete withMutableCharacters in 5.0
* Obsolete customPlaygroundQuickLook in 5.0
* Deprecate Zip2Sequence streams in 5.0
* Replace * with swift on lotsa stuff
* Back off obsoleting playground conformances for now
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
`CS.solve()` with `FreeTypeVariableBinding::Disallow` still may emit
unresolved type. e.g. `DeclRefExpr` to decl with unresolved type.
https://bugs.swift.org/browse/SR-8568
rdar://problem/43433253
* Replace bodies of Comparable versions with calls to sort(by:)
* Make _insertionSort a method
* Make _sort3 a method
* Make _partition a method
* Make _introSort a method
* Make _siftDown, _heapify, _heapsort methods
* Other minor cleanup
A Dictionary.removeValue(forKey:) benchmark regressed 35% because recent changes in this PR caused an _UnsafeBitMap member to not be inlined in its implementation. (This was probably triggered by moving a method from Dictionary._Variant to _NativeDictionary.)
Add @inline(__always) to _UnsafeBitMap members.
While we’re at it, make _UnsafeBitMap @usableFromInline. It’s only public for testing purposes.
Unresolved type attached to expressions may fail re-typechecking.
Also, disallow unresolved type in typeCheckCompletionSequence(). It doesn't
provide useful completions to developers.
rdar://problem/41224316
The name-lookup behavior that avoids looking for members of a nominal type
or extension therefore when resolving the inheritance clause is now
handled by UnqualifiedLookup, so remove it from the type checker itself.
Fixes rdar://problem/39130543.
Existence of semantic expr (`getSemanticExpr()`) prevents ASTWalker
walking into the *original* sub expressions which may cause
re-typechecking failure. For example,
`ConstraintGenerator::visitArrayExpr()` assumes we already visited its
elements, but that's not the case if the semantic expr exists.
rdar://problem/42639255
