It wasn't properly handling the cases where the bound was in the
opposite direction from the amount, when advancing random access
indices.
Swift SVN r20123
Marking these generic functions as transparent results in our not
emitting diagnostics for unreachable code if these functions are the
only code in a block and inlining generic code is enabled (due to
<rdar://problem/17687851>).
I don't believe other diagnostics benefit in any way from having these
marked as @transparent, and removing @transparent actually improved
Ackerman at -O3 by 15%.
Swift SVN r19996
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
And make RandomAccessIndex refine it.
* had to XFAIL
test/Prototypes/TextFormatting.swift (<rdar://problem/17619178>)
* Had to compromise on the name of Strideable's associated
type (<rdar://problem/17619038>)
Swift SVN r19785
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
Also, don't diagnose accessibility violations on implicit decls. Every now
and then the compiler needs to bend the rules, such as when providing an ==
implementation for a local enum.
Swift SVN r19519
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
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
