Commit Graph

100 Commits

Author SHA1 Message Date
Alex Crichton
1b5f9cb1f1 std: Add an option to disable ELF based TLS
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.
2015-05-28 10:14:42 -07:00
Alex Crichton
150663c3b6 mk: Correct names of installed libs on windows
Previously libmorestack.a and libcompiler-rt.a were installed, but link.exe
looks for morestack.lib and compiler-rt.lib by default, so we need to install
these with the correct name
2015-05-19 10:36:00 -07:00
Michael Sproul
1174114356 Add error index generator. 2015-05-03 22:08:25 +10:00
Alex Crichton
cd980b3bee mk: Add support for musl-based builds
This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:

* Any target of the form `*-musl` requires the `--musl-root` option to
  `./configure` which will indicate the root of the MUSL installation. It is
  also expected that there is a libunwind build inside of that installation
  built against that MUSL.

* Objects from MUSL are copied into the build tree for Rust to be statically
  linked into the appropriate Rust library.

* Objects for binary startup and shutdown are included in each Rust installation
  by default for MUSL. This requires MUSL to only be installed on the machine
  compiling rust. Only a linker will be necessary for compiling against MUSL on
  a target machine.

Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.
2015-04-27 10:11:15 -07:00
bors
7a5754b330 Auto merge of #24428 - kwantam:deprecate_unicode_fns, r=alexcrichton
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
   librustc_driver and libsyntax. This may change pretty-printed
   output from these modules in cases involving wide or combining
   characters used in filenames, identifiers, etc.

The following functions are marked deprecated:

1. char.width() and str.width():
   --> use unicode-width crate

2. str.graphemes() and str.grapheme_indices():
   --> use unicode-segmentation crate

3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
   char.compose(), char.decompose_canonical(), char.decompose_compatible(),
   char.canonical_combining_class():
   --> use unicode-normalization crate
2015-04-18 07:09:22 +00:00
Niko Matsakis
966e53d8b6 Add librustc_data_structures crate 2015-04-17 10:12:53 -04:00
kwantam
29d1252e4d deprecate Unicode functions that will be moved to crates.io
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
   librustc_driver and libsyntax. This may change pretty-printed
   output from these modules in cases involving wide or combining
   characters used in filenames, identifiers, etc.

The following functions are marked deprecated:

1. char.width() and str.width():
   --> use unicode-width crate

2. str.graphemes() and str.grapheme_indices():
   --> use unicode-segmentation crate

3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
   char.compose(), char.decompose_canonical(), char.decompose_compatible(),
   char.canonical_combining_class():
   --> use unicode-normalization crate
2015-04-16 17:03:05 -04:00
Alex Crichton
ed276caeec mk: Stop documenating non-facade crates
This commit ceases documentation-by-default of crates such as `term`,
`serialize`, and `alloc`. Crates like `term` and `rand` have duplicates on
`crates.io` and the search index entries generated in the local tree end up
only leading to confusion. Crates like the entire compiler infrastructure,
`flate`, or `rbml` don't need to be documented in such a prominent location.

This change also means that doc tests will no longer be run for crates beyond
the facade (e.g. `serialize` or `term`), but there were very few doc tests in
there to begin with.

Closes #22168
2015-04-07 17:54:34 -07:00
Corey Richardson
b314fedc4a mk: build and distribute facade crates unconditionally (for now) 2015-03-30 19:18:47 -04:00
Corey Richardson
e64b677ca6 mk: don't build docs for internal or behind-the-facade crates in beta/stable
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want compiler docs during development.

Crates behind the facade are only documented on nightly/dev builds (where they
can be used).

[breaking-change]

Closes #23772
Closes #21297
2015-03-29 06:15:51 -04:00
Huon Wilson
532cd5f85a Separate most of rustc::lint::builtin into a separate crate.
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from

    librustc -> librustc_typeck -> ... -> librustc_driver ->
        libcore -> ... -> libstd

to

    librustc_lint -> librustc_driver -> libcore -> ... libstd

which is significantly faster, mainly due to avoiding the librustc build
itself.

The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.

This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.

This should make #22206 easier.
2015-02-28 15:33:59 +11:00
Alex Crichton
6c29708bf9 regex: Remove in-tree version
The regex library was largely used for non-critical aspects of the compiler and
various external tooling. The library at this point is duplicated with its
out-of-tree counterpart and as such imposes a bit of a maintenance overhead as
well as compile time hit for the compiler itself.

The last major user of the regex library is the libtest library, using regexes
for filters when running tests. This removal means that the filtering has gone
back to substring matching rather than using regexes.
2015-01-23 21:04:10 -08:00
Alex Crichton
34fa70fba5 std: Move the bitflags! macro to a gated crate
In accordance with [collections reform part 2][rfc] this macro has been moved to
an external [bitflags crate][crate] which is [available though
crates.io][cratesio]. Inside the standard distribution the macro has been moved
to a crate called `rustc_bitflags` for current users to continue using.

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0509-collections-reform-part-2.md
[crate]: https://github.com/rust-lang/bitflags
[cratesio]: http://crates.io/crates/bitflags

The major user of `bitflags!` in terms of a public-facing possibly-stable API
today is the `FilePermissions` structure inside of `std::io`. This user,
however, will likely no longer use `bitflags!` after I/O reform has landed. To
prevent breaking APIs today, this structure remains as-is.

Current users of the `bitflags!` macro should add this to their `Cargo.toml`:

    bitflags = "0.1"

and this to their crate root:

    #[macro_use] extern crate bitflags;

Due to the removal of a public macro, this is a:

[breaking-change]
2015-01-17 10:51:07 -05:00
Alex Crichton
a9decbdc44 rustc: Move the privacy pass to its own crate 2015-01-16 08:38:24 -08:00
Steve Klabnik
16a6ebd1f6 "The Rust Programming Language"
This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."

A few things motivated this change:

* People knew of The Guide, but not the individual Guides. This merges
  them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
  is nice.
* We now have rustbook in-tree, which can generate this kind of
  documentation. While its style is basic, the general idea is much
  better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
  per section.
2015-01-08 12:02:11 -05:00
Alex Crichton
7d8d06f86b Remove deprecated functionality
This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.

Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).

The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.
2015-01-03 23:43:57 -08:00
Alex Crichton
48048419b1 mk: Stop generating docs for deprecated crates
These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.

Closes #20096
2014-12-28 09:34:38 -08:00
Eduard Burtescu
c54fc980f3 Split resolve from rustc::middle into rustc_resolve. 2014-12-20 07:28:47 +02:00
Aaron Turon
2b3477d373 libs: merge librustrt into libstd
This commit merges the `rustrt` crate into `std`, undoing part of the
facade. This merger continues the paring down of the runtime system.

Code relying on the public API of `rustrt` will break; some of this API
is now available through `std::rt`, but is likely to change and/or be
removed very soon.

[breaking-change]
2014-12-18 23:31:34 -08:00
Niko Matsakis
2854d1bfc2 Separate borrowck into its own crate and remove dead code as well. 2014-12-13 06:01:19 -05:00
Niko Matsakis
61edb0ccb7 Separate the driver into its own crate that uses trans, typeck. 2014-12-04 10:04:52 -05:00
Niko Matsakis
93eb4333a0 Move typeck into its own crate. 2014-12-04 10:04:52 -05:00
Aaron Turon
985acfdb67 Merge libsync into libstd
This patch merges the `libsync` crate into `libstd`, undoing part of the
facade. This is in preparation for ultimately merging `librustrt`, as
well as the upcoming rewrite of `sync`.

Because this removes the `libsync` crate, it is a:

[breaking-change]

However, all uses of `libsync` should be able to reroute through
`std::sync` and `std::comm` instead.
2014-11-24 10:51:39 -08:00
Aaron Turon
40c78ab037 Fallout from libgreen and libnative removal 2014-11-20 17:19:24 -08:00
Aaron Turon
3ee916e50b Remove libnative
With runtime removal complete, there's nothing left of libnative. This
commit removes it.

Fixes #18687

[breaking-change]
2014-11-20 17:19:13 -08:00
Niko Matsakis
dc6e414e6f Move trans, back, driver, and back into a new crate, rustc_trans. Reduces memory usage significantly and opens opportunities for more parallel compilation. 2014-11-18 07:32:43 -05:00
Alex Crichton
b39f1dcba0 Remove rlibc from the distribution
To make progress on #18585 we're paring down the distribution to theoretically
"only libstd", and this commit makes progress on this by removing the rlibc
crate from the distribution.

The crate has now been moved into an external cargo package located in the rust
lang organization [1]. This is a breaking change due to this removal, and
existing crates depending on `rlibc` should use the Cargo crate instead.

[1]: https://github.com/rust-lang/rlibc

[breaking-change]
cc #18585
2014-11-06 13:37:55 -08:00
Alex Crichton
fb169d5543 Remove a number of deprecated crates
All of these crates have been deprecated for some time and properly live in the
rust-lang organization as cargo-based crates.

To update your code, depend on the rust-lang/foo repository via cargo.

[breaking-change]
2014-10-19 12:59:40 -07:00
Luqman Aden
26e547af5d libsyntax: Remove all uses of {:?}. 2014-10-16 11:15:34 -04:00
Felix S. Klock II
b63a18f585 compiletest needs to link to native crate, or at least the rt library.
(I tried using a dependency on `rustrt` instead, and that did not
resolve the problem.  But this does.)

Fix #17883
2014-10-11 11:08:15 +02:00
Aaron Turon
002643dcf0 Remove librustuv
This commit removes the `librustuv` crate.

See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]
2014-10-01 10:34:39 -07:00
Keegan McAllister
8826fdfe37 Keep ExpnId abstract by providing conversions 2014-09-28 09:25:48 -07:00
Niko Matsakis
3694f42b8c Move checking of whether fields are Sized or not into wf / trait code. 2014-09-25 07:09:13 -04:00
Niko Matsakis
713cf373c1 Take core as a dependency on librlibc. This is needed so that it can
see the lang-items for Sized etc. @acrichto and @thestinger had no
objections.
2014-09-15 14:58:49 -04:00
Eduard Burtescu
d6fb338d01 syntax: ast_map: use borrowed references into the AST. 2014-09-14 03:39:36 +03:00
Nick Cameron
cc9b2b0550 Allow a regex filter for RUST_LOG
When specifying RUST_LOG, the programmer may append `/regex` to the end of the spec. All results will then be filtered using that regex.
2014-08-28 10:14:57 +12:00
Erick Tryzelaar
e1dcbefe52 remove serialize::ebml, add librbml
Our implementation of ebml has diverged from the standard in order
to better serve the needs of the compiler, so it doesn't make much
sense to call what we have ebml anyore. Furthermore, our implementation
is pretty crufty, and should eventually be rewritten into a format
that better suits the needs of the compiler. This patch factors out
serialize::ebml into librbml, otherwise known as the Really Bad
Markup Language. This is a stopgap library that shouldn't be used
by end users, and will eventually be replaced by something better.

[breaking-change]
2014-07-31 07:30:49 -07:00
Brian Anderson
cf360f328a Extract librustc_back from librustc 2014-07-14 12:27:07 -07:00
Brian Anderson
d3096c2348 Move llvm bindings to their own crate 2014-07-14 12:27:07 -07:00
kwantam
85e2bee4a2 fix test failures
- unicode tests live in coretest crate
- libcollections str tests need UnicodeChar trait.
- libregex perlw tests were checking a char in the Alphabetic category,
  \x2161. Confirmed perl 5.18 considers this a \w character. Changed to
  \x2961, which is not \w as the test expects.
2014-07-09 10:14:46 -04:00
kwantam
5d4238b6fc Add libunicode; move unicode functions from core
- created new crate, libunicode, below libstd
- split Char trait into Char (libcore) and UnicodeChar (libunicode)
  - Unicode-aware functions now live in libunicode
    - is_alphabetic, is_XID_start, is_XID_continue, is_lowercase,
      is_uppercase, is_whitespace, is_alphanumeric, is_control,
      is_digit, to_uppercase, to_lowercase
  - added width method in UnicodeChar trait
    - determines printed width of character in columns, or None if it is
      a non-NULL control character
    - takes a boolean argument indicating whether the present context is
      CJK or not (characters with 'A'mbiguous widths are double-wide in
      CJK contexts, single-wide otherwise)
- split StrSlice into StrSlice (libcore) and UnicodeStrSlice
  (libunicode)
  - functionality formerly in StrSlice that relied upon Unicode
    functionality from Char is now in UnicodeStrSlice
    - words, is_whitespace, is_alphanumeric, trim, trim_left, trim_right
  - also moved Words type alias into libunicode because words method is
    in UnicodeStrSlice
- unified Unicode tables from libcollections, libcore, and libregex into
  libunicode
- updated unicode.py in src/etc to generate aforementioned tables
- generated new tables based on latest Unicode data
- added UnicodeChar and UnicodeStrSlice traits to prelude
- libunicode is now the collection point for the std::char module,
  combining the libunicode functionality with the Char functionality
  from libcore
  - thus, moved doc comment for char from core::char to unicode::char
- libcollections remains the collection point for std::str

The Unicode-aware functions that previously lived in the Char and
StrSlice traits are no longer available to programs that only use
libcore. To regain use of these methods, include the libunicode crate
and use the UnicodeChar and/or UnicodeStrSlice traits:

    extern crate unicode;
    use unicode::UnicodeChar;
    use unicode::UnicodeStrSlice;
    use unicode::Words; // if you want to use the words() method

NOTE: this does *not* impact programs that use libstd, since UnicodeChar
and UnicodeStrSlice have been added to the prelude.

closes #15224
[breaking-change]
2014-07-07 14:52:24 -04:00
Alex Crichton
b1c9ce9c6f sync: Move underneath libstd
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.

There were a few notable changes and a few breaking changes as part of this
movement:

* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
  reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
  It is now a private module with types/functions being reexported under
  `sync::comm`. This is a breaking change for any existing users of duplex
  streams.
* All concurrent queues/deques were moved directly under libsync. They are also
  all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
  live under `std::sync`. They will forever live at this location, but they may
  move to libsync if the `std::task` module moves as well.

[breaking-change]
2014-06-11 10:00:43 -07:00
Keegan McAllister
deecda6a94 Macro crates now depend on librustc 2014-06-09 14:29:30 -07:00
Alex Crichton
5ec36c358f std: Extract librustrt out of libstd
As part of the libstd facade efforts, this commit extracts the runtime interface
out of the standard library into a standalone crate, librustrt. This crate will
provide the following services:

* Definition of the rtio interface
* Definition of the Runtime interface
* Implementation of the Task structure
* Implementation of task-local-data
* Implementation of task failure via unwinding via libunwind
* Implementation of runtime initialization and shutdown
* Implementation of thread-local-storage for the local rust Task

Notably, this crate avoids the following services:

* Thread creation and destruction. The crate does not require the knowledge of
  an OS threading system, and as a result it seemed best to leave out the
  `rt::thread` module from librustrt. The librustrt module does depend on
  mutexes, however.
* Implementation of backtraces. There is no inherent requirement for the runtime
  to be able to generate backtraces. As will be discussed later, this
  functionality continues to live in libstd rather than librustrt.

As usual, a number of architectural changes were required to make this crate
possible. Users of "stable" functionality will not be impacted by this change,
but users of the `std::rt` module will likely note the changes. A list of
architectural changes made is:

* The stdout/stderr handles no longer live directly inside of the `Task`
  structure. This is a consequence of librustrt not knowing about `std::io`.
  These two handles are now stored inside of task-local-data.

  The handles were originally stored inside of the `Task` for perf reasons, and
  TLD is not currently as fast as it could be. For comparison, 100k prints goes
  from 59ms to 68ms (a 15% slowdown). This appeared to me to be an acceptable
  perf loss for the successful extraction of a librustrt crate.

* The `rtio` module was forced to duplicate more functionality of `std::io`. As
  the module no longer depends on `std::io`, `rtio` now defines structures such
  as socket addresses, addrinfo fiddly bits, etc. The primary change made was
  that `rtio` now defines its own `IoError` type. This type is distinct from
  `std::io::IoError` in that it does not have an enum for what error occurred,
  but rather a platform-specific error code.

  The native and green libraries will be updated in later commits for this
  change, and the bulk of this effort was put behind updating the two libraries
  for this change (with `rtio`).

* Printing a message on task failure (along with the backtrace) continues to
  live in libstd, not in librustrt. This is a consequence of the above decision
  to move the stdout/stderr handles to TLD rather than inside the `Task` itself.
  The unwinding API now supports registration of global callback functions which
  will be invoked when a task fails, allowing for libstd to register a function
  to print a message and a backtrace.

  The API for registering a callback is experimental and unsafe, as the
  ramifications of running code on unwinding is pretty hairy.

* The `std::unstable::mutex` module has moved to `std::rt::mutex`.

* The `std::unstable::sync` module has been moved to `std::rt::exclusive` and
  the type has been rewritten to not internally have an Arc and to have an RAII
  guard structure when locking. Old code should stop using `Exclusive` in favor
  of the primitives in `libsync`, but if necessary, old code should port to
  `Arc<Exclusive<T>>`.

* The local heap has been stripped down to have fewer debugging options. None of
  these were tested, and none of these have been used in a very long time.

[breaking-change]
2014-06-06 22:19:41 -07:00
Alex Crichton
5cdc36517e mk: Move rust_test_helpers out of libstd
There's no need to distribute these ABI helpers for tests with the standard rust
distribution they're only needed for our tests.

Closes #2665
2014-06-05 17:55:41 -07:00
Alex Crichton
6a585375a0 std: Recreate a collections module
As with the previous commit with `librand`, this commit shuffles around some
`collections` code. The new state of the world is similar to that of librand:

* The libcollections crate now only depends on libcore and liballoc.
* The standard library has a new module, `std::collections`. All functionality
  of libcollections is reexported through this module.

I would like to stress that this change is purely cosmetic. There are very few
alterations to these primitives.

There are a number of notable points about the new organization:

* std::{str, slice, string, vec} all moved to libcollections. There is no reason
  that these primitives shouldn't be necessarily usable in a freestanding
  context that has allocation. These are all reexported in their usual places in
  the standard library.

* The `hashmap`, and transitively the `lru_cache`, modules no longer reside in
  `libcollections`, but rather in libstd. The reason for this is because the
  `HashMap::new` contructor requires access to the OSRng for initially seeding
  the hash map. Beyond this requirement, there is no reason that the hashmap
  could not move to libcollections.

  I do, however, have a plan to move the hash map to the collections module. The
  `HashMap::new` function could be altered to require that the `H` hasher
  parameter ascribe to the `Default` trait, allowing the entire `hashmap` module
  to live in libcollections. The key idea would be that the default hasher would
  be different in libstd. Something along the lines of:

      // src/libstd/collections/mod.rs

      pub type HashMap<K, V, H = RandomizedSipHasher> =
            core_collections::HashMap<K, V, H>;

  This is not possible today because you cannot invoke static methods through
  type aliases. If we modified the compiler, however, to allow invocation of
  static methods through type aliases, then this type definition would
  essentially be switching the default hasher from `SipHasher` in libcollections
  to a libstd-defined `RandomizedSipHasher` type. This type's `Default`
  implementation would randomly seed the `SipHasher` instance, and otherwise
  perform the same as `SipHasher`.

  This future state doesn't seem incredibly far off, but until that time comes,
  the hashmap module will live in libstd to not compromise on functionality.

* In preparation for the hashmap moving to libcollections, the `hash` module has
  moved from libstd to libcollections. A previously snapshotted commit enables a
  distinct `Writer` trait to live in the `hash` module which `Hash`
  implementations are now parameterized over.

  Due to using a custom trait, the `SipHasher` implementation has lost its
  specialized methods for writing integers. These can be re-added
  backwards-compatibly in the future via default methods if necessary, but the
  FNV hashing should satisfy much of the need for speedier hashing.

A list of breaking changes:

* HashMap::{get, get_mut} no longer fails with the key formatted into the error
  message with `{:?}`, instead, a generic message is printed. With backtraces,
  it should still be not-too-hard to track down errors.

* The HashMap, HashSet, and LruCache types are now available through
  std::collections instead of the collections crate.

* Manual implementations of hash should be parameterized over `hash::Writer`
  instead of just `Writer`.

[breaking-change]
2014-06-05 13:55:10 -07:00
bors
aa09561bb6 auto merge of #14633 : huonw/rust/nodylibc, r=alexcrichton
libc: only provide an rlib.

There's absolutely no reason for `libc` to be offered as a dynamic
library.
2014-06-04 15:26:50 -07:00
Huon Wilson
96cc48fba2 libc: only provide an rlib.
There's absolutely no reason for `libc` to be offered as a dynamic
library.
2014-06-04 19:10:40 +10:00
Steven Fackler
c56c286b10 Remove libworkcache
This was only ever used by rustpkg and is very unmaintained.

[breaking-change]
2014-05-30 23:44:05 -07:00
Alex Crichton
925ff65118 std: Recreate a rand module
This commit shuffles around some of the `rand` code, along with some
reorganization. The new state of the world is as follows:

* The librand crate now only depends on libcore. This interface is experimental.
* The standard library has a new module, `std::rand`. This interface will
  eventually become stable.

Unfortunately, this entailed more of a breaking change than just shuffling some
names around. The following breaking changes were made to the rand library:

* Rng::gen_vec() was removed. This has been replaced with Rng::gen_iter() which
  will return an infinite stream of random values. Previous behavior can be
  regained with `rng.gen_iter().take(n).collect()`

* Rng::gen_ascii_str() was removed. This has been replaced with
  Rng::gen_ascii_chars() which will return an infinite stream of random ascii
  characters. Similarly to gen_iter(), previous behavior can be emulated with
  `rng.gen_ascii_chars().take(n).collect()`

* {IsaacRng, Isaac64Rng, XorShiftRng}::new() have all been removed. These all
  relied on being able to use an OSRng for seeding, but this is no longer
  available in librand (where these types are defined). To retain the same
  functionality, these types now implement the `Rand` trait so they can be
  generated with a random seed from another random number generator. This allows
  the stdlib to use an OSRng to create seeded instances of these RNGs.

* Rand implementations for `Box<T>` and `@T` were removed. These seemed to be
  pretty rare in the codebase, and it allows for librand to not depend on
  liballoc.  Additionally, other pointer types like Rc<T> and Arc<T> were not
  supported.  If this is undesirable, librand can depend on liballoc and regain
  these implementations.

* The WeightedChoice structure is no longer built with a `Vec<Weighted<T>>`,
  but rather a `&mut [Weighted<T>]`. This means that the WeightedChoice
  structure now has a lifetime associated with it.

* The `sample` method on `Rng` has been moved to a top-level function in the
  `rand` module due to its dependence on `Vec`.

cc #13851

[breaking-change]
2014-05-29 16:18:26 -07:00