All the integers already have an init() that will narrow from Max[U]Int.
This change is consistent with our general move from factories to
initializers.
Swift SVN r21988
Unsupported architectures will cause a failure to compile rather than
some kind of runtime trap. In particular, assert() should never be used
in the standard library; we have _sanityCheck for that purpose.
Swift SVN r21373
When an integer type T is used as an Index, there are always
bounds---more restrictive than the full range of T---against which we're
not able to check. Overflows are not useful indicators of precondition
violations in this context. Therefore, use masked arithmetic for
RandomAccessIndex conformance.
Performance changes of magnitude >= 5% are below. Someone might want to
investigate why Fibonacci got 21% faster in -Ounchecked, since nothing
in this change should have removed checks from that build. (That test
does seem particularly sensitive; see also <rdar://problem/17815767>
Adding three overloads to stdlib slows Fibonacci by 18-19%)
Fixes <rdar://problem/17780469> Integer ranges shouldn't use overflowing adds
====================`PrecommitBench_O`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
````Ackermann`|``1428.00`|``1466.00`|`1661.00`|`1657.00`|`229.00`|``-13.8%`
`````ForLoops`|``2021.00`|``1986.00`|`1249.00`|`1255.00`|`737.00`|```59.0%`
`````````Hash`|``1038.00`|```979.00`|``898.00`|``922.00`|``81.00`|````9.0%`
`````````Life`|````63.00`|````63.00`|```60.00`|```61.00`|```3.00`|````5.0%`
```````Memset`|````55.00`|````54.00`|```42.00`|```42.00`|``12.00`|```28.6%`
``MonteCarloE`|``1243.00`|``1265.00`|``885.00`|``880.00`|`363.00`|```41.3%`
`MonteCarloPi`|```994.00`|``1004.00`|``613.00`|``605.00`|`389.00`|```64.3%`
````````NBody`|````45.00`|````45.00`|```42.00`|```43.00`|```3.00`|````7.1%`
````QuickSort`|```105.00`|```103.00`|```83.00`|```83.00`|``20.00`|```24.1%`
````R17315246`|``1080.00`|``1080.00`|``805.00`|``808.00`|`275.00`|```34.2%`
``````SmallPT`|``1008.00`|``1007.00`|``789.00`|``795.00`|`218.00`|```27.6%`
````````Walsh`|```136.00`|```136.00`|``129.00`|``130.00`|```7.00`|````5.4%`
====================`PrecommitBench_Ounchecked`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
``Dictionary3`|``1060.00`|``1039.00`|``982.00`|`1029.00`|``57.00`|````5.8%`
````Fibonacci`|```842.00`|```848.00`|``694.00`|``694.00`|`148.00`|```21.3%`
```StringWalk`|```945.00`|```924.00`|``989.00`|``995.00`|``65.00`|```-6.6%`
====================`PrecommitBench_Onone`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
`EditDistance`|``2086.00`|``1981.00`|`1492.00`|`1622.00`|`489.00`|```32.8%`
`````````Life`|``1256.00`|``1216.00`|`1110.00`|`1142.00`|`106.00`|````9.5%`
```````MatMul`|``1210.00`|``1245.00`|``705.00`|``705.00`|`505.00`|```71.6%`
````R17315246`|```205.00`|```209.00`|``195.00`|``200.00`|``10.00`|````5.1%`
Swift SVN r20576
...because their semantics were unclear. The new idiom is explicit
construction of the target type using the "bitPattern:" argument label:
myInt.toUnsigned() => UInt(bitPattern: myInt)
Fixes <rdar://problem/17000821>
Swift SVN r20479
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
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
Sliceable is a totally non-critical protocol and Range slicing wasn't
even being tested. Along with r19771, fixes <rdar://problem/16363898>
Swift SVN r19775
This horrible hack prevents the user from indexing Range<I>, for all
integer types I, outside of a generic context. This seems to be the
best we can do to prevent confusion given the current language.
Addresses <rdar://problem/16363898>
Unfortunately, I can't make this work for slicing ranges yet.
Swift SVN r19771
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
- Follow LLVM conventions for emacs mode specification
- Use local variables suffix to make the output read-only (at least on
Emacs)
- But drop the admonitions not to edit the generated files;
line-directive mostly takes care of that problem now.
Swift SVN r19381
As before, there may be more things marked @public than we actually want
public. Judicious use of the frontend option -disable-access-control may
help reduce the public surface area of the stdlib.
Swift SVN r19353
This just renames the existing "uncheckedAdd" (and related) functions to addWithOverflow. These
were already "checked" and return the partial result + bool that we want.
Swift SVN r19246
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
This is motivated by <rdar://problem/17051606>.
This ends up renaming variables as well, which seems right for
consistency since we use "predicate" as variable name.
Swift SVN r19135
