Commit Graph

1263 Commits

Author SHA1 Message Date
Daniel Micay
d884cc83b0 remove unnecessary PaX detection
Rust no longer has support for JIT compilation, so it doesn't currently
require a PaX MPROTECT exception. The extended attributes are preferred
over modifying the binaries so it's not actually going to work on most
systems like this anyway.

If JIT compilation ends up being supported again, it should handle this
by *always* applying the exception via an extended attribute without
performing auto-detection of PaX on the host. The `paxctl` tool is only
necessary with the older method involving modifying the ELF binary.
2014-06-13 13:53:35 -07:00
Alex Crichton
fa7b7bcdcb mk: Allow using a locally compiled libuv.a
Closes 
2014-06-12 00:29:58 -07:00
Alex Crichton
145e415fab mk: Allow usage of a local jemalloc install
This adds a new configure option, --jemalloc-root, which will specify a location
at which libjemalloc_pic.a must live. This library is then used for the build
triple as the jemalloc library to link.
2014-06-12 00:28:01 -07:00
Alex Crichton
b1c9ce9c6f sync: Move underneath libstd
This commit is the final step in the libstd facade, . 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
bors
c690191a84 auto merge of : alexcrichton/rust/issue-14747, r=huonw
When generating documentation, rustdoc has the ability to generate relative
links within the current distribution of crates to one another. To do this, it
must recognize when a crate's documentation is in the same output directory. The
current threshold for "local documentation for crate X being available" is
whether the directory "doc/X" exists.

This change modifies the build system to have new dependencies for each
directory of upstream crates for a rustdoc invocation. This will ensure that
when building documentation that all the crates in the standard distribution are
guaranteed to have relative links to one another.

This change is prompted by guaranteeing that offline docs always work with one
another. Before this change, races could mean that some docs were built before
others, and hence may have http links when relative links would suffice.

Closes 
2014-06-10 19:52:05 -07:00
Keegan McAllister
deecda6a94 Macro crates now depend on librustc 2014-06-09 14:29:30 -07:00
Alex Crichton
992a2db1fc mk: Ensure docs have relative links to each other
When generating documentation, rustdoc has the ability to generate relative
links within the current distribution of crates to one another. To do this, it
must recognize when a crate's documentation is in the same output directory. The
current threshold for "local documentation for crate X being available" is
whether the directory "doc/X" exists.

This change modifies the build system to have new dependencies for each
directory of upstream crates for a rustdoc invocation. This will ensure that
when building documentation that all the crates in the standard distribution are
guaranteed to have relative links to one another.

This change is prompted by guaranteeing that offline docs always work with one
another. Before this change, races could mean that some docs were built before
others, and hence may have http links when relative links would suffice.

Closes 
2014-06-09 13:00:18 -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
e5bbbca33e rustdoc: Submit examples to play.rust-lang.org
This grows a new option inside of rustdoc to add the ability to submit examples
to an external website. If the `--markdown-playground-url` command line option
or crate doc attribute `html_playground_url` is present, then examples will have
a button on hover to submit the code to the playground specified.

This commit enables submission of example code to play.rust-lang.org. The code
submitted is that which is tested by rustdoc, not necessarily the exact code
shown in the example.

Closes 
2014-06-06 20:00:16 -07:00
Alex Crichton
cb12e7ab74 mk: Run doc tests with --cfg dox
There were a few examples in the macros::builtin module that weren't being run
because they were being #[cfg]'d out.

Closes 
2014-06-06 19:51:52 -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 
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
073c8f10fc auto merge of : alexcrichton/rust/rustdoc-links, r=huonw
These are a few assorted fixes for some issues I found this morning (details in the commits).
2014-06-04 22:21:43 -07:00
bors
aa09561bb6 auto merge of : 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
Alex Crichton
890754794c mk: Less noisy rustdoc invocations 2014-06-01 21:53:43 -07: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 

[breaking-change]
2014-05-29 16:18:26 -07:00
bors
812785e01a auto merge of : luqmana/rust/docs, r=alexcrichton
We were still generating compiler docs even with --disable-docs passed.

cc @pnkfelix
2014-05-28 18:21:34 -07:00
Alex Crichton
b53454e2e4 Move std::{reflect,repr,Poly} to a libdebug crate
This commit moves reflection (as well as the {:?} format modifier) to a new
libdebug crate, all of which is marked experimental.

This is a breaking change because it now requires the debug crate to be
explicitly linked if the :? format qualifier is used. This means that any code
using this feature will have to add `extern crate debug;` to the top of the
crate. Any code relying on reflection will also need to do this.

Closes 

[breaking-change]
2014-05-27 21:44:51 -07:00
Luqman Aden
213d54e06c mk: Don't build any docs with --disable-docs. 2014-05-27 20:17:17 -04:00
bors
489f470886 auto merge of : cmr/rust/design-faq, r=brson
This indends to help quell frequently answered questions about the language
design in a single, authoritative place.
2014-05-25 03:01:20 -07:00
Corey Richardson
11c0f77107 doc: add a new language design faq
This indends to help quell frequently answered questions about the language
design in a single, authoritative place.
2014-05-25 02:53:53 -07:00
Luqman Aden
69e246fdc9 Add clang specific flag more selectively. 2014-05-23 17:27:13 -07:00
bors
a0960a1223 auto merge of : alexcrichton/rust/doc.rust-lang.org, r=huonw 2014-05-22 16:56:23 -07:00
Alex Crichton
799ddba8da Change static.rust-lang.org to doc.rust-lang.org
The new documentation site has shorter urls, gzip'd content, and index.html
redirecting functionality.
2014-05-21 19:55:39 -07:00
bors
5f3f0918ad auto merge of : brson/rust/deoxidize, r=alexcrichton
Using `rustc` instead of e.g. `compile` makes it clear this is a rust build step.
2014-05-21 13:11:28 -07:00
Brian Anderson
7c8c544731 mk: Replace 'oxidize' with 'rustc'. Closes 2014-05-21 11:01:59 -07:00
Felix S. Klock II
ae67b74ec8 Make configure respect (and save) values for CC, CXX, CFLAGS, etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.

The overall intention is to capture the following precedences for
guessing the C compiler:

 1. Value of `CC` at make invocation time.
 2. Value of `CC` at configure invocation time.
 3. Compiler inferred at configure invocation time (`gcc` or `clang`).

The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).

Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.

Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS`
values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings.
(This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various
parts of the mk files.)

Fix .

----

Note that if you try to set the compiler to clang via the `CC` and
`CXX` environment variables, you will probably need to also set
`CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured
properly.

----

Introduce CFG_USING_CLANG, which is distinguished from
CFG_ENABLE_CLANG because the former represents "we think we're using
clang, choose appropriate warning-control options" while the latter
represents "we asked configure (or the host required) that we attempt
to use clang, so check that we have an appropriate version of clang."

The main reason I added this is that I wanted to allow the user to
choose clang via setting the `CC` environment variable, but I did not
want that method of selection to get confused with the user passing
the `--enable-clang` option.

----

A digression: The `configure` script does not infer the compiler
setting if `CC` is set; but if `--enable-clang` was passed, then it
*does* still attempt to validate that the clang version is compatible.

Supporting this required revising `CLANG_VERSION` check to be robust
in face of user-provided `CC` value.

In particular, on Travis, the `CC` is set to `gcc` and so the natural
thing to do is to attempt to use `gcc` as the compiler, but Travis is
also passing `--enable-clang` to configure.  So, what is the right
answer in the face of these contradictory requests?

One approach would be to have `--enable-clang` supersede the setting
for `CC` (and instead just call whatever we inferred for `CFG_CLANG`).
That sounds maximally inflexible to me (pnkfelix): a developer
requesting a `CC` value probably wants it respected, and should be
able to set it to something else; it is harder for that developer to
hack our configure script to change its inferred path to clang.

A second approach would be to blindly use the `CC` value but keep
going through the clang version check when `--enable-clang` is turned
on.  But on Travis (a Linux host), the `gcc` invocation won't print a
clang version, so we would not get past the CLANG_VERSION check in
that context.

A third approach would be to never run the CLANG_VERSION check if `CC`
is explicitly set.  That is not a terrible idea; but if the user uses
`CC` to pass in a path to some other version of clang that they want
to test, probably should still send that through the `CLANG_VERSION`
check.

So in the end I (pnkfelix) took a fourth approach: do the
CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string
ending with `clang`.  This way setting `CC` to things like
`path/to/clang` or `ccache clang` will still go through the
CLANG_VERSION check, while setting `CC` to `gcc` or some unknown
compiler will skip the CLANG_VERSION check (regardless of whether the
user passed --enable-clang to `configure`).

----

Drive-by fixes:

* The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in
  its invocation, but that does not play nicely with someone who sets
  `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret
  that whole string as a command.

  (On the other hand, a path with spaces might need the quoted
  invocation.  Not sure which one of these corner use-cases is more
  important to support.)

* Fix chk_cc error message to point user at `gcc` not `cc`.
2014-05-20 21:37:08 +02:00
Felix S. Klock II
8cbda5da93 Refactoring: Introduce distinct host and target rpath var setters.
Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added
RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup.

`HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)`
both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which
is still being set the same way that it was before, to one of either
HOST/TARGET depending on what stage we are building).  Namely, the format
is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>"

What this commit does:

* Pass both of the (newly introduced) HOST and TARGET rpath setup vars
  to `maketest.py`

* Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself
  Instead, it passes along the HOST and TARGET rpath setup vars in
  environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV`

* Also, pass the current stage number to maketest.py; it in turn
  passes it (via an env var) to run-make tests.

  This allows the run-make tests to selectively change behavior
  (e.g. turn themselves off) to deal with incompatibilities with
  e.g. stage1.

* Cleanup: Distinguish in tools.mk between the command to run (`RUN`)
  and the file to generate to drive that command (`RUN_BINFILE`).  The
  main thing this enables is that `RUN` can now setup the
  `TARGET_RPATH_ENV` without having to dirty up the runner code in
  each of the `run-make` Makefiles.

* Cleanup: Factored out commands to delete dylib/rlib into
  REMOVE_DYLIBS/REMOVE_RLIBS.

  There were places where we were only calling `rm $(call DYLIB,foo)`
  even though we really needed to get rid of the whole glob (at least
  based on alex's findings on  that removing the symlink does not
  suffice).

  Therefore rather than peppering the code with the awkward
  `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common
  `REMOVE_DYLIBS` user function that expands into that when called.
  After I adding an analogous `REMOVE_RLIBS`, I changed all of the
  existing calls that rm dylibs or rlibs to use these routines
  instead.

  Note that the latter is not a true refactoring since I may have
  changed cases where it was our intent to only remove the sym-link.
  (But if that is the case, then we need to more deeply investigate
  alex's findings on  where the system was still dynamically
  loading up the non-symlinked libraries that it finds on the load
  path.)

* Added RPATH_LINK_SEARCH command and use it on Linux.

  On some platforms, namely Linux, when you have libboot.so that has
  its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the
  linker still complains when you do the link step and it does not
  know where to find libraries that libboot.so depends upon that live
  in HOSTDIR (think e.g. librustuv.so).

  As far as I can tell, the GNU linker will consult the
  LD_LIBRARY_PATH as part of the linking process to find such
  libraries.  But if you want to be more careful and not override
  LD_LIBRARY_PATH for the `gcc` invocation, then you need some other
  way to tell the linker where it can find the libraries that
  libboot.so needs.  The solution to this on Linux is the
  `-Wl,-rpath-link` command line option.

  However, this command line option does not exist on Mac OS X, (which
  appears to be figuring out how to resolve the libboot.dylib
  dependency by some other means, perhaps by consulting the rpath
  setting within libboot.dylib).

  So, in order to abstract over this distinction, I added the
  RPATH_LINK_SEARCH macro to the run-make infrastructure and added
  calls to it where necessary to get Linux working.  On architectures
  other than Linux, the macro expands to nothing.

* Disable miscellaneous tests atop stage1.

* An especially interesting instance of the previous bullet point:
  Excuse regex from doing rustdoc tests atop stage1.

  This was a (nearly-) final step to get `make check-stage1` working
  again.

  The use of a special-case check for regex here is ugly but is
  analogous other similar checks for regex such as the one that landed
  in PR .

  The way this is written, the user will get a reminder that
  doc-crate-regex is being skipped whenever their rules attempt to do
  the crate documentation tests.  This is deliberate: I want people
  running `make check-stage1` to be reminded about which cases are
  being skipped.  (But if such echo noise is considered offensive, it
  can obviously be removed.)

* Got windows working with the above changes.

  This portion of the commit is a cleanup revision of the (previously
  mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH
  setup and extension is handled in order to accommodate Windows' (1.)
  use of `$PATH` for that purpose and (2.) use of spaces in `$PATH`
  entries (problematic for make and for interoperation with tools at
  the shell).

* In addition, since the code has been rearchitected to pass the
  HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh
  environment-variable setting command, there is no need to for the
  convert_path_spec calls in maketest.py, which in fact were put in
  place to placate Windows but were now causing the Windows builds to
  fail.  Instead we just convert the paths to absolute paths just like
  all of the other path arguments.

Also, note for makefile hackers: apparently you cannot quote operands
to `ifeq` in Makefile (or at least, you need to be careful about
adding them, e.g. to only one side).
2014-05-18 22:56:26 +02:00
Alex Crichton
639759b7f4 std: Refactor liballoc out of lib{std,sync}
This commit is part of the libstd facade RFC, issue . This creates a new
library, liballoc, which is intended to be the core allocation library for all
of Rust. It is pinned on the basic assumption that an allocation failure is an
abort or failure.

This module has inherited the heap/libc_heap modules from std::rt, the owned/rc
modules from std, and the arc module from libsync. These three pointers are
currently the three most core pointer implementations in Rust.

The UnsafeArc type in std::sync should be considered deprecated and replaced by
Arc<Unsafe<T>>. This commit does not currently migrate to this type, but future
commits will continue this refactoring.
2014-05-17 21:52:23 -07:00
Kevin Ballard
8ef3e22719 Optimize and fix time::precise_time_ns() on macos
Use sync:1️⃣:Once to fetch the mach_timebase_info only once when
running precise_time_ns(). This helps because mach_timebase_info() is
surprisingly inefficient. Also fix the order of operations when applying
the timebase to the mach absolute time value.

This improves the time on my machine from

```
test tests::bench_precise_time_ns ... bench:       157 ns/iter (+/- 4)
```

to

```
test tests::bench_precise_time_ns ... bench:        38 ns/iter (+/- 3)
```

and it will get even faster once  lands.
2014-05-16 14:02:14 -07:00
Corey Richardson
f923b93694 term: add docs and windows support
Closes 
2014-05-16 09:57:32 -07:00
bors
bbd034c3a6 auto merge of : alexcrichton/rust/issue-14144, r=cmr
By default, jemalloc is building itself with -g3 if the local compiler supports
it. It looks like this is generating a good deal of debug info that windows
isn't optimizing out (on the order of 18MB). Windows gcc/ld is also not
optimizing this data away, causing hello world to be 18MB in size.

There's no current real need for debugging jemalloc to a great extent, so this
commit manually passes -g1 to override -g3 which jemalloc is using. This is
confirmed to drop the size of executables on windows back to a more reasonable
size (2.0MB, as they were before).

Closes 
2014-05-16 02:46:25 -07:00
Alex Crichton
161b50a8e6 mk: Don't build jemalloc with -g3
By default, jemalloc is building itself with -g3 if the local compiler supports
it. It looks like this is generating a good deal of debug info that windows
isn't optimizing out (on the order of 18MB). Windows gcc/ld is also not
optimizing this data away, causing hello world to be 18MB in size.

There's no current real need for debugging jemalloc to a great extent, so this
commit manually passes -g1 to override -g3 which jemalloc is using. This is
confirmed to drop the size of executables on windows back to a more reasonable
size (2.0MB, as they were before).

Closes 
2014-05-15 15:45:55 -07:00
Richo Healey
b05af1f6a8 Render not_found with an absolute path to the rust stylesheet 2014-05-15 13:50:45 -07:00
Felix S. Klock II
aaf398f26a Graphviz based flow graph pretty-printing.
Passing `--pretty flowgraph=<NODEID>` makes rustc print a control flow graph.

In pratice, you will also need to pass the additional option:
`-o <FILE>` to emit output to a `.dot` file for graphviz.

(You can only print the flow-graph for a particular block in the AST.)

----

An interesting implementation detail is the way the code puts both the
node index (`cfg::CFGIndex`) and a reference to the payload
(`cfg::CFGNode`) into the single `Node` type that is used for
labelling and walking the graph.  I had once mistakenly thought that I
only wanted the `cfg::CFGNode`, but for labelling, you really want the
cfg index too, rather than e.g. trying to use the `ast::NodeId` as the
label (which breaks down e.g. due to `ast::DUMMY_NODE_ID`).

----

As a drive-by fix, I had to fix `rustc::middle::cfg::construct`
interface to reflect changes that have happened on the master branch
while I was getting this integrated into the compiler.  (The next
commit actually adds tests of the `--pretty flowgraph` functionality,
so that should ensure that the `rustc::middle::cfg` code does not go
stale again.)
2014-05-15 13:50:42 -07:00
Alex Crichton
a7bee7b05d Add a crate for missing stubs from libcore
The core library in theory has 0 dependencies, but in practice it has some in
order for it to be efficient. These dependencies are in the form of the basic
memory operations provided by libc traditionally, such as memset, memcmp, etc.
These functions are trivial to implement and themselves have 0 dependencies.

This commit adds a new crate, librlibc, which will serve the purpose of
providing these dependencies. The crate is never linked to by default, but is
available to be linked to by downstream consumers. Normally these functions are
provided by the system libc, but in other freestanding contexts a libc may not
be available. In these cases, librlibc will suffice for enabling execution with
libcore.

cc 
2014-05-15 13:50:37 -07:00
Alex Crichton
bfbd732dae mk: Don't run benchmarks with make check
The current suite of benchmarks for the standard distribution take a significant
amount of time to run, but it's unclear whether we're gaining any benefit from
running them. Some specific pain points:

* No one is looking at the data generated by the benchmarks. We have no graphs
  or analysis of what's happening, so all the data is largely being cast into
  the void.

* No benchmark has ever uncovered a bug, they have always run successfully.

* Benchmarks not only take a significant amount of time to run, but also take a
  significant amount of time to compile. I don't think we should mitigate this
  for now because it's useful to ensure that they do indeed still compile.

This commit disables --bench test runs by default as part of `make check`,
flipping the NO_BENCH environment variable to a PLEASE_BENCH variable which will
manually enable benchmarking. If and when a dedicated bot is set up for
benchmarking, this flag can be enabled on that bot.
2014-05-15 13:50:14 -07:00
Huon Wilson
19f9181654 test: allow the test filter to be a regex.
This is fully backwards compatible, since test names are Rust
identifiers + `:`, and hence not special regex characters.

Fixes .
2014-05-15 23:04:09 +10:00
Luqman Aden
d0d800f125 Get rid of the android-cross-path flag to rustc.
There's no need to include this specific flag just for android. We can
already deal with what it tries to solve by using -C linker=/path/to/cc
and -C ar=/path/to/ar. The Makefiles for rustc already set this up when
we're crosscompiling.

I did add the flag to compiletest though so it can find gdb. Though, I'm
pretty sure we don't run debuginfo tests on android anyways right now.

[breaking-change]
2014-05-14 02:16:14 -04:00
Richo Healey
ef23fa17c3 docs: Add a not found page 2014-05-13 17:24:07 -07:00
Brian Anderson
c1da4f875f Add the patch number to version strings. Closes 2014-05-12 19:52:29 -07:00
Daniel Micay
f1735cefcf make sure jemalloc valgrind support is enabled
This requires pointing it at the valgrind headers we carry in-tree.
2014-05-11 20:05:22 -04:00
Alex Crichton
034f218061 mk: Bundle jemalloc with make dist
The dist tarball doesn't depend on git, so all git submodules must be included
inside of it.
2014-05-11 17:41:36 -04:00
Daniel Micay
e2479b8cac pass correct CFLAGS for jemalloc 2014-05-11 00:07:21 -04:00
Daniel Micay
1b1ca6d546 add back jemalloc to the tree
This adds a `std::rt::heap` module with a nice allocator API. It's a
step towards fixing  and is a starting point for working on a
generic allocator trait.

The revision used for the jemalloc submodule is the stable 3.6.0 release.

Closes 
2014-05-10 19:58:17 -04:00
bors
d8781b36fc auto merge of : alexcrichton/rust/libfmt, r=brson
This code does not belong in libstd, and rather belongs in a dedicated crate. In
the future, the syntax::ext::format module should move to the fmt_macros crate
(hence the name of the crate), but for now the fmt_macros crate will only
contain the format string parser.

The entire fmt_macros crate is marked #[experimental] because it is not meant
for general consumption, only the format!() interface is officially supported,
not the internals.

This is a breaking change for anyone using the internals of std::fmt::parse.
Some of the flags have moved to std::fmt::rt, while the actual parsing support
has all moved to the fmt_macros library.

[breaking-change]
2014-05-08 12:26:39 -07:00
Alex Crichton
80487ddcad std: Extract format string parsing out of libstd
This code does not belong in libstd, and rather belongs in a dedicated crate. In
the future, the syntax::ext::format module should move to the fmt_macros crate
(hence the name of the crate), but for now the fmt_macros crate will only
contain the format string parser.

The entire fmt_macros crate is marked #[experimental] because it is not meant
for general consumption, only the format!() interface is officially supported,
not the internals.

This is a breaking change for anyone using the internals of std::fmt::parse.
Some of the flags have moved to std::fmt::rt, while the actual parsing support
has all moved to the fmt_macros library.

[breaking-change]
2014-05-08 09:35:59 -07:00
Alex Crichton
6aefce6f16 mk: Fix make install
Forgot to update the installation procedure with the knowledge that libcore is
only available as an rlib, not as a dylib.

Closes 
2014-05-07 23:23:17 -07:00