The timeouts have a comment about ASan tests taking hours, but that comment is a decade old and that doesn't seem to be the case now. Reflection_objc.swift does take over a minute to build with an ASan compiler, but that's tolerable.
rdar://134405526
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
