From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
This decreases total testing time by over a minute on my old Mac Pro.
It probably has much less effect on systems with fewer cores, but shouldn't
be any worse there.
Swift SVN r22745
This function mixes the bits in the hash value, which improves Dictionary
performance for keys with bad hashes.
PrecommitBenchmark changes with greater than 7% difference:
``````````Dictionary2`,```1456.00`,```1508.00`,```1502.00`,````624.00`,````607.00`,````592.00`,`864.00`,``145.9%
``````````Dictionary3`,```1379.00`,```1439.00`,```1408.00`,````585.00`,````567.00`,````552.00`,`827.00`,``149.8%
````````````Histogram`,````850.00`,````849.00`,````851.00`,```1053.00`,```1049.00`,```1048.00`,`199.00`,``-19.0%
````````````````Prims`,```1999.00`,```2005.00`,```2018.00`,```1734.00`,```1689.00`,```1701.00`,`310.00`,```18.4%
``````````StrSplitter`,```2365.00`,```2334.00`,```2316.00`,```1979.00`,```1997.00`,```2000.00`,`337.00`,```17.0%
```````````````TwoSum`,```1551.00`,```1568.00`,```1556.00`,```1771.00`,```1741.00`,```1716.00`,`165.00`,```-9.6%
Regressions are in benchmarks that use `Int` as dictionary key: we are just
doing more work than previously (hashing an `Int` was an identity function).
rdar://17962402
Swift SVN r21142
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20518
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
1) Add an ObjCObject disposition that tells us this Mirror is reflecting upon an ObjC-imported type
2) Change the default summary of _ClassMirror and _StructMirror to be the mangled typename, with no children count
Swift SVN r19817
This commit removes Mirrors for RangeGenerators, since Dave and I discussed that these won't be necessary in practice
Also, it removes the Mirrors for Range types from Range.swift.gyb, and instead adds a new RangeMirrors.swift.gyb used to generate range types Mirrors
Swift SVN r19543
The one design choice here was whether to expose the pointee directly through the Mirror
My choice was against that. Instead, we present UnsafePointer as UnsafePointer(0x123) and the child we expose is the 0x123 numeric pointer value
The other option, of course, would be to present it as UnsafePointer(reflect(memory)) - but that seems risky to do by default
UnsafePointers are allowed to be in, guess what, unsafe states, and the stakes of having playgrounds try and dereference at all times are quite too high.
If the user really wants to reflect the pointee reflect(pointer.memory) will do it for them - and then any crashes will be theirs to enjoy.
Of course, I am very open to arguments as to why reflect(memory) would be a better choice.
Swift SVN r19386
Our runtime doesn't fix up class field offset vectors for resilient ObjC base classes, causing the offsets to be wrong if the actual size of the base class differs from its compile-time claimed size. Use the ObjC runtime's ivar records instead if the class has ObjC heritage. We can't do this all the time because the ObjC ivar records aren't yet trustworthy for generic classes, but we don't fully support the mix of ObjC heritage and genericity very well anyway yet. Fixes <rdar://problem/17027510> in the short term.
Swift SVN r18622
This is our public API for how quicklooks work in the debugger, and the plan is to have this same API work in playgrounds as well
Fixes rdar://17023157
Swift SVN r18609
The <opaque> output is clearly useless, and annoying to see scattered around playgrounds
We don't have bandwidth right now to produce detailed useful reflection information, but at least show a basic understanding of data
Fixes part of rdar://17018392
Swift SVN r18607
- rdar://problem/16776273, wherein conversions between nil and .None were permitted
due to an implicit conversion between nil and COpaquePointer.
- rdar://problem/16877526, where we needed to add new equality overloads to handle
conversions between nil and .None given the supression of user conversions.
(Thanks to Ted for the overloads and test.)
Swift SVN r18473
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
creating a Dictionary from a dictionary literal
Also fixes rdar://16876745, because once the code moved to using lower-level
interfaces, it became trivial to detect duplicate keys without a performance
hit.
Swift SVN r18193
