StringByteData was legacy detritus containing an in-memory UTF8
representation of a Swift string. Since we switched to a UTF16 base
representation, use the new stuff in StringUTF8 instead.
Swift SVN r16968
We need something here so we can rip out StringByteData. Ideally this
would have BidirectionalIndex'es, but this will do for now. It has to
be a Collection so we can represent its multi-pass-ness.
Swift SVN r16966
When we build the standard libary with -parse-stdlib the frontend sets the
assert configuration to 'DisableReplacement'. Constant replacement does not take
place and the call to the builtin function 'assert_configuration' call stays in
the serialize SIL of the swiftmodule.
IRGen replaces the function call to the assert_configuration builtin function by
the value for Debug (0). The resuling standard library dylib hence contains the
debug version of the standard library assert function.
Frontend optimization flags can now determine whether asserts should be executed
or not.
This commit removes the SWIFT_ASSERTS cmake flag.
rdar://16458612
Swift SVN r16473
With this check-in, we get Mirrors for IntXX, UIntXX, Float32, and we don't lose the existing ones for Double, Int, String and Bool
This fixes rdar://16517273 and will make playgrounds able to display more data more often more consistently!
Swift SVN r16418
The name may have the wrong implication to a C++'er, but the point is
that this Collection is a Lazy version of the map() function. Maybe we
should be giving our Collections capitalized lazy versions of their
member algorithms, e.g.
a.Map {something}
Swift SVN r16110
Array's getObjects:range: needs to fill the supplied buffer without
incrementing the reference count. For that reason, and to fulfill
lifetime expectations for Array elements that are computed
dynamically (e.g. from value types that are BridgedToObjectiveC), we
maintain a cache of converted objects associated with each Array.
Swift SVN r16105
Just moving things between files, and creating a few new source files, in
the standard library, so it's easier to find a given component.
Swift SVN r16094
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
