There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
Replacing the old key with the new is unnecessary and somewhat surprising. It is also harmful to some usecases.
rdar://problem/32144087
# Conflicts:
# stdlib/public/core/NativeDictionary.swift
This will minimize the chance of breaking code. Currently SwiftLint
has one "too complex" expression with this change. Further changes to
the solver may improve that situation, and potentially allow us to
move this out from -swift-version 5 if we're willing to take the risk
of breaking some code as a result.
Because binding producer is going to attempt to unwrap optionals
and try the type, which would lead to infinite recursion because
dependent member types aren't bindable.
Resolves: rdar://problem/44770297
Along with updating tests to adopt the new storage class names, the behavior of removeAll() has changed slightly.
If t stored an empty Set/Dictionary that was bridged from Objective-C, t.removeAlI() used to keep the original Objective-C storage intact. Now removeAll() replaces the old storage with the empty singleton, which makes a lot more sense to me.
Bitsets implement sorted sets over nonnegative integers up to a predetermined maximum value.
These are intended to replace _UnsafeBitMap. The latter will be removed once its usages are eliminated.
- _UnsafeBitset.Word is the underlying abstraction, implementing a bitset using a single UInt value.
- _UnsafeBitset is a view over a contiguous range of words.
- _Bitset is a COW value type implementing the same construct.
Like we did for structs, make it so that tuple types can also get extra inhabitants from whichever element with the most, not only the first. This lets us move all of the extra inhabitant handling functionality between structs and tuples in IRGen up to the common RecordTypeInfo CRTP base.
Attempt to visit disjunctions that are associated with applies where
we have at least some useful information about the types of all of the
arguments before visiting other disjunctions.
Two tests here got faster, and one slightly slower. One of the
faster tests is actually moving from test/ to the slow/ directory in
validation-test because despite going from 16s to less than 1s, it was
still borderline for what we consider the slow threshold, so I made
the test more complex. The one that got a little slower is
rdar22022980, which I also made more complex so that it is clearly
"slow" by the way we are testing it.
slower:
rdar22022980.swift
faster:
rdar33688063.swift
expression_too_complex_4.swift
The witness table for an empty, resilient protocol might need to be
instantiated, if a newer version of the protocol contains defaulted
associated type requirements. In such cases, we would either fail to
instantiate or assert in the runtime. Replace the assertion with a
proper check (to require instantiation in such cases) and cope with
filling in defaults even when the provided generic witness table has
no resilient witnesses.
For a resilient protocol that has defaulted associated types, emit
default associated conformance witnesses that compute associated
conformances based on that default witness.
This completes the implementation of resilience protocols that
add new, defaulted associated types, rdar://problem/44167982.
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
Generic parameter references, which occur in generic requirement
metadata, were hardcoding associated type indices. Instead, use
relative references to associated type descriptors and perform the
index calculation at runtime.
Associated types can now be reordered resiliently (without relying on
sorting), which is the first main step toward rdar://problem/44167982.
We can use the extra inhabitants of the type metadata field as extra inhabitants of the entire
existential container, allowing `Any?` and similar types to be the same size as non-optional
existentials.
* add count(where:) and tests
* Revise count(where:) documentation
* Remove errant word in abstract
* add a benchmark for ranges and strings with help from @natecook1000
* update benchmark to use Array instead of Range
