Go to file

Felix S. Klock II d6bf04a22e Add `CodeExtent::Remainder` variant; pre-req for new scoping/drop rules. This new variant introduces finer-grain code extents, i.e. we now track that a binding lives only for a suffix of a block, and (importantly) will be dropped when it goes out of scope before the bindings that occurred earlier in the block. Both of these notions are neatly captured by marking the block (and each suffix) as an enclosing scope of the next suffix beneath it. This is work that is part of the foundation for issue #8861. (It actually has been seen in earlier posted pull requests; I have just factored it out into its own PR to ease my own rebasing.) ---- These finer grained scopes do mean that some code is newly rejected by `rustc`; for example: ```rust let mut map : HashMap<u8, &u8> = HashMap::new(); let tmp = Box::new(2); map.insert(43, &tmp); ``` This will now fail to compile with a message that `tmp` does not live long enough, because the scope of `tmp` is now strictly smaller than that of `map`, and the use of `&u8` in map's type requires that the borrowed references are all to data that live at least as long as the map. The usual fix for a case like this is to move the binding for `tmp` up above that of `map`; note that you can still leave the initialization in the original spot, like so: ```rust let tmp; let mut map : HashMap<u8, &u8> = HashMap::new(); tmp = box 2; map.insert(43, &tmp); ``` Similarly, one can encounter an analogous situation with `Vec`: one would need to rewrite: ```rust let mut vec = Vec::new(); let tmp = 'c'; vec.push(&tmp); ``` as: ``` let tmp; let mut vec = Vec::new(); tmp = 'c'; vec.push(&tmp); ``` ---- In some corner cases, it does not suffice to reorder the bindings; in particular, when the types for both bindings need to reflect exactly the same* code extent, and a parent/child relationship between them does not work. In pnkfelix's experience this has arisen most often when mixing uses of cyclic data structures while also allowing a lifetime parameter `'a` to flow into a type parameter context where the type is invariant with respect to the type parameter. An important instance of this is `arena::TypedArena<T>`, which is invariant with respect to `T`. (The reason that variance is relevant is this: if `TypedArena` were covariant with respect to its type parameter, then we could assign it the longer lifetime when it is initialized, and then convert it to a subtype (via covariance) with a shorter lifetime when necessary. But `TypedArena` is invariant with respect to its type parameter, and thus if `S` is a subtype of `T` (in particular, if `S` has a lifetime parameter that is shorter than that of `T`), then a `TypedArena<S>` is unrelated to `TypedArena<T>`.) Concretely, consider code like this: ```rust struct Node<'a> { sibling: Option<&'a Node<'a>> } struct Context<'a> { // because of this field, `Context<'a>` is invariant with respect to `'a`. arena: &'a TypedArena<Node<'a>>, ... } fn new_ctxt<'a>(arena: &'a TypedArena<Node<'a>>) -> Context<'a> { ... } fn use_ctxt<'a>(fcx: &'a Context<'a>) { ... } let arena = TypedArena::new(); let ctxt = new_ctxt(&arena); use_ctxt(&ctxt); ``` In these situations, if you try to introduce two bindings via two distinct `let` statements, each is (with this commit) assigned a distinct extent, and the region inference system cannot find a single region to assign to the lifetime `'a` that works for both of the bindings. So you get an error that `ctxt` does not live long enough; but moving its binding up above that of `arena` just shifts the error so now the compiler complains that `arena` does not live long enough. SO: What to do? The easiest fix in this case is to ensure that the two bindings do get assigned the same static extent, by stuffing both bindings into the same let statement, like so: ```rust let (arena, ctxt): (TypedArena, Context); arena = TypedArena::new(); ctxt = new_ctxt(&arena); use_ctxt(&ctxt); ``` Due to the new code rejections outlined above, this is a ... [breaking-change]		2015-01-27 10:26:52 +01:00
man
mk	Auto merge of #21582 - FlaPer87:rollup, r=brson	2015-01-25 13:33:18 +00:00
src	Add `CodeExtent::Remainder` variant; pre-req for new scoping/drop rules.	2015-01-27 10:26:52 +01:00
.gitattributes
.gitignore
.gitmodules
.mailmap
.travis.yml
AUTHORS.txt
configure	Auto merge of #21582 - FlaPer87:rollup, r=brson	2015-01-25 13:33:18 +00:00
CONTRIBUTING.md
COPYRIGHT
LICENSE-APACHE
LICENSE-MIT
Makefile.in
README.md	Auto merge of #21242 - richo:no-perl, r=brson	2015-01-21 11:07:31 +00:00
RELEASES.md

README.md

The Rust Programming Language

This is a compiler for Rust, including standard libraries, tools and documentation.

Quick Start

Download a binary installer for your platform.
Read The Rust Programming Language.
Enjoy!

Note: Windows users can read the detailed using Rust on Windows notes on the wiki.

Building from Source

Make sure you have installed the dependencies:
- g++ 4.7 or clang++ 3.x
- python 2.6 or later (but not 3.x)
- GNU make 3.81 or later
- curl
- git
Download and build Rust:

You can either download a tarball or build directly from the repo.

To build from the tarball do:
```
 $ curl -O https://static.rust-lang.org/dist/rust-nightly.tar.gz
 $ tar -xzf rust-nightly.tar.gz
 $ cd rust-nightly
```
Or to build from the repo do:
```
 $ git clone https://github.com/rust-lang/rust.git
 $ cd rust
```
Now that you have Rust's source code, you can configure and build it:
```
 $ ./configure
 $ make && make install
```
Note: You may need to use sudo make install if you do not normally have permission to modify the destination directory. The install locations can be adjusted by passing a --prefix argument to configure. Various other options are also supported, pass --help for more information on them.

When complete, make install will place several programs into /usr/local/bin: rustc, the Rust compiler, and rustdoc, the API-documentation tool.
Read The Rust Programming Language.
Enjoy!

Building on Windows

To easily build on windows we can use MSYS2:

Grab the latest MSYS2 installer and go through the installer.
Now from the MSYS2 terminal we want to install the mingw64 toolchain and the other tools we need.

# choose one based on platform
$ pacman -S mingw-w64-i686-toolchain
$ pacman -S mingw-w64-x86_64-toolchain

$ pacman -S base-devel

With that now start mingw32_shell.bat or mingw64_shell.bat from where you installed MSYS2 (i.e. C:\msys). Which one you choose depends on if you want 32 or 64 bit Rust.
From there just navigate to where you have Rust's source code, configure and build it:
```
 $ ./configure
 $ make && make install
```

Notes

Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier state of development). As such, source builds require a connection to the Internet, to fetch snapshots, and an OS that can execute the available snapshot binaries.

Snapshot binaries are currently built and tested on several platforms:

Windows (7, 8, Server 2008 R2), x86 and x86-64 (64-bit support added in Rust 0.12.0)
Linux (2.6.18 or later, various distributions), x86 and x86-64
OSX 10.7 (Lion) or greater, x86 and x86-64

You may find that other platforms work, but these are our officially supported build environments that are most likely to work.

Rust currently needs about 1.5 GiB of RAM to build without swapping; if it hits swap, it will take a very long time to build.

There is a lot more documentation in the wiki.

Getting help and getting involved

The Rust community congregates in a few places:

StackOverflow - Get help here.
/r/rust - General discussion.
discuss.rust-lang.org - For development of the Rust language itself.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.