The ArrayType protocol is developed for NewArray is a good basis for
what we want, but the ability to create arrays without value semantics
is adding complexity but questionable value. It isn't clear that we can
usefully expose a type called SharedArray<T>, even internally, if it
ceases to be truly shared when one copy grows, and therefore has its
buffer reallocated. Therefore, leave the NewArray test with a
ArrayType2, a refinement of ArrayType, that adds the ability to report
on its value semantics.
If we really want the optimizations that can be had in a large-scale
mutation by first unique'ing the array and making mutations in-place
thereafter, we can fall back to operating on NativeArrayBuffer<T>
directly.
Swift SVN r15673
Turns out CMake's PRE_BUILD mode for custom commands doesn't work with the
Ninja or Makefile generators (not sure about Xcode). Just do it as part of
an earlier target instead.
Swift SVN r14968
Before this commit, RandomAccessIndex was a refinement of
NumericOperations, which forced it to support inappropriate operations
such as multiplication. Many obvious random-access index types can't
support multiplication (e.g. a StridedIndex adapter, which moves its
underlying index by N positions for each increment).
Along the way:
* the addition and subtraction operations on RandomAccessIndex were
renamed to advancedBy and distanceTo, which prevents nasty ambiguities
when a type conforms to both RandomAccessIndex and Integer, and allows
Index DistanceTypes to actually be signed integers even when the Index
is unsigned.
* Before this commit, using internal interfaces, it was possible to
request static checking without also getting dynamic checks when
static checking is impossible. Now the relationship between static
and dynamic checking is built into the core protocols.
* NumericOperations.swift was moved into IntegerArithmetic.swift.gyb,
correcting missing operators by generating them programmatically and
in preparation for renaming the protocol to something more appropriate
Fixes
<rdar://problem/16246927> RandomAccessIndex is over-constrained
and possibly:
<rdar://problem/15605729> Make all operators generic over
protocols (in particular, get NumericOperations done)
Swift SVN r14854
To support layering improvements, add an (optionally built) "essential
core" library containing the minimum set of files required just to link
successfully. Right now all those object files are linked again into
swift_stdlib_core; it would probably be better to link the essential
core into the core, but my CMake/Swift Driver fu is not strong enough
and this will at least help during development.
Along the way, removed the obsolete SwiftStdlibSources.txt file, as we
only have to support one build system now.
Swift SVN r14792
It's dead, Jim. Also remove 'ClassNameable' since we don't use it for anything.
Reapply r14647 now that John fixed the serialization issue that scuttled it last time.
Swift SVN r14722
Remove all gyb-generated files and generate them automatically from .gyb
files. Rename the proof-of-concept UnsafeArray.swift.gyb back to
UnsafeArray.swift. Never forget to update the .gyb file or regenerate
again!
Swift SVN r14445
Now a "foo.bar.gyb" file in a list of sources gets automatically
processed through gyb to produce "foo.bar"
Renamed a simple .swift file in the stdlib (which needs a rename anyway)
to have a .gyb extension as a proof-of-concept.
To make this useful for our existing gyb files, we need to figure out
how to pass them the right arguments; that's coming next.
Swift SVN r14444
Define a "Mirror" protocol with methods for querying the number of children a structured value has, getting the name and mirror for each of those children, and a string and "IDE representation" of the value, as needed by playgrounds and by our planned generic printing facility.
In the runtime, define a "reflect" function that can provide a Mirror for any object, either using a "Reflectable" protocol conformance if available, or falling back to a magic implementation in the runtime that grovels the type metadata. Stub out a bare minimum default implementation.
Swift SVN r14139
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
Will serve as an IndexType for CollectionOfOne<T>
Open Question: should this become a full-fledged Int1 type, generated by
FixedPoint.gyb?
Swift SVN r13974
Sometimes you just need to normalize to the widest integer
type (especially in generic code), and who knows; someday we may get
Int128 back.
Swift SVN r13950
As part of this, have the standard library target be responsible for
symlinking Clang's headers into the resource directory, instead of the
compiler target. This makes sure the headers show up in all copies of
the build directory.
This brings our iOS testing closer to what Xcode will do, which will
hopefully avoid issues like <rdar://problem/16052579>.
Swift SVN r13890
This re-applies r13380, reverted in r13406. I don't think this actually
caused any harm (r13400 was the primary culprit), but if it did I'd
like to actually see the buildbots or someone else's machine fail on it.
Swift SVN r13456
