Builds on 36eae9d4f6 to emit a message instead of just trapping
when a switch over a non-frozen enum ends up not matching anything.
If the enum is known to be an @objc enum, the message is
unexpected enum case 'MyEnum(rawValue: -42)'
and if it's anything else (a Swift enum, a tuple containing enums,
whatever), it's a more opaque
unexpected enum case while switching on value of type 'MyEnum'
The reason for this is to avoid calling String(describing:) or
String(reflecting:) an arbitrary value when the enum might conform to
CustomStringConvertible and therefore /itself/ have a switch that's
going to fall off the end. By handling plain @objc enums (using a
bitcast), we've at least covered the 90% case.
rdar://problem/37728359
Usually this happens directly, through some use of the class and its
conformance. However, if a conformance is /only/ used to satisfy an
associated type, we seem to bypass the step that actually infers
selector names for accessors, even though we do it successfully for
methods. Fix this by making sure the accessor decls are validated when
a property is, something that normal uses of a property probably have
to do anyway.
Also, simplify inferObjCName by assuming/asserting that it is only
used on things that are already marked @objc.
https://bugs.swift.org/browse/SR-6944
We were hitting an unreachable in visitDynamicMemberExpr in ExprRewriter when
re-typechecking during a salvage. Check for these earlier (in CSGen) and update
SanitizeExpr to handle them.
Resolves rdar://problem/39055736
The amp_prefix token is currently tolerated in any unary expression
context and then diagnosed later by Sema. This patch changes parsing to
only accept tok::amp_prefix in its allowed position: parameter lists.
This also fixes two "compiler crasher" tests.
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
`PreCheckExpression` should only walk into associated closure if
it's a single statement, and should avoid list itself since it should
already be properly type-checked by `typeCheckDecl`.
Resolves: rdar://problem/34852808
Switch StringObject and StringGuts from opaquely storing tagged cocoa
strings into storing small strings. Plumb small string support
throughout the standard library's routines.
Streamline internal String creation. Previously, everything funneled
into a single generic function, however, every single call of the
generic funnel had relevant specific information that could be used
for a more efficient algorithm.
In preparation for efficiently forming small strings, refactor this
logic into a handful of more specialized subroutines to preserve more
specific information from the callers.
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
With the exception of “has type variable”, which affects the arena used
for storage of a BoundNameAliasType, only propagate recursive properties
from the underlying type to a BoundNameAliasType, because the other
properties (e.g., “has archetype” or “has type parameter”) pulled from
syntactic sugar don’t apply.
This assumes these will land in Swift 4.1; the attributes need to be adjusted if that turns out not to be the case.
It seems @available for protocol conformances is not yet functional. I added attributes for those anyway, marked with FIXME(conformance-availability).
# Conflicts:
# stdlib/public/core/ExistentialCollection.swift.gyb
# stdlib/public/core/Mirror.swift
Now that Array and Dictionary conform to Hashable, we need to make sure that their bridged counterparts provide the same hash values when converted to AnyHashable.
* Add conditional Hashable conformance to Optional, Dictionary, Array, ArraySlice and ContiguousArray
* Modified hashValue implementations
The hashValues are now calculated similar to the automatically synthesized values when conforming to Hashable.
This entails using _combineHashValues as values of the collections are iterated - as well as calling _mixInt before returning the hash.
* Added FIXMEs as suggested by Max Moiseev
* Use checkHashable to check Hashable conformance
* Use 2 space indentation
* Hashing of Dictionary is now independent of traversal order
* Added a test to proof failure of (previous) wrong implementation of Dictionary hashValue. Unfortunately it does not work.
* Removed '_mixInt' from 'hashValue' implementation of Optional and Array types based on recommendations from lorentey
* Another attempt at detecting bad hashing due to traversal order
* Dictionary Hashable validation tests now detect bad hashing due to dependence on traversal order
* Removed superfluous initial _mixInt call for Dictionary hashValue implementation.
* Add more elements to dictionary in test to increase the number of possible permutations - making it more likely to detect order-dependent hashes
* Added Hashable conformance to CollectionOfOne, EmptyCollection and Range types
* Fix indirect referral to the only member of CollectionOfOne
* Re-added Hashable conformance to Range after merge from master
* Change hashValue based on comment from @lorentey
* Remove tests for conditional Hashable conformance for Range types. This is left for a followup PR
* Added tests for CollectionOfOne and EmptyCollection
* Added conditional conformance fo Equatable and Hashable for DictionaryLiteral. Added tests too.
* Added conditional Equatable and Hashable conformance to Slice
* Use 'elementsEqual' for Slice equality operator
* Fixed documentation comment and indentation
* Fix DictionaryLiteral equality implementation
* Revert "Fix DictionaryLiteral equality implementation"
This reverts commit 7fc1510bc3.
* Fix DictionaryLiteral equality implementation
* Use equalElements(:by:) to compare DictionaryLiteral elements
* Added conditional conformance for Equatable and Hashable to AnyCollection
* Revert "Use 'elementsEqual' for Slice equality operator"
This reverts commit 0ba2278b96.
* Revert "Added conditional Equatable and Hashable conformance to Slice"
This reverts commit 84f9934bb4.
* Added conditional conformance for Equatable and Hashable for ClosedRange
Currently, when we reference a (non-generic) typealias within a
generic context, we would completely lose type sugar for the
typealias, replacing it with the underlying type. Instead, use
BoundNameAliasType for this purpose, which allows us to maintain all
of the type sugar as well as storing complete substitutions for later
use.
The DeclChecker had three possible states:
- IsFirstPass true, IsSecondPass false. This is the 'first pass' for
declarations that appear at the top-level, or are nested inside
top-level types.
- IsFirstPass false, IsSecondPass true. This is the 'second pass' for
declarations that appear at the top-level, or are nested inside
top-level types.
- IsFirstPass false, IsSecondPass false. This was used for (some)
local declarations.
This is unnecessarily confusing. We can eliminate the third state
by calling typeCheckDecl() twice in a few places. This allows
IsSecondPass to be removed entirely since it's now always equal to
!IsFirstPass.
Stress tests are, by definition, stressful. They intentionally burn a
lot of resources by using randomness to hopefully surface state machine
bugs. Additionally, many stress tests are multi-threaded these days and
they may attempt to use all of the available CPUs to better uncover
bugs. In isolation, this is not a problem, but the test suite as a whole
assumes that individual tests are single threaded and therefore running
multiple stress tests at once can quickly spiral out of control.
This change formalizes stress tests and then treats them like long
tests, i.e. tested via 'check-swift-all' and otherwise opt-in.
Finally, with this change, the CI build bots might need to change if
they are still only testing 'validation' instead of all of the tests.
I see three options:
1) Run all of the tests. -- There are very few long tests left these
days, and the additional costs seems small relative to the cost of
the whole validation test suite before this change.
2) Continue checking 'validation', now sans stress tests.
3) Check 'validation', *then* the stress tests. If the former doesn't
pass, then there is no point in the latter, and by running the stress
tests separately, they stand a better chance of uncovering bugs and
not overwhelming build bot resources.
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
