Commit Graph

1023 Commits

Author SHA1 Message Date
HeroesGrave
d81bb441da moved collections from libextra into libcollections 2014-02-07 19:49:26 +13:00
bors
87fe3ccf09 auto merge of #12039 : alexcrichton/rust/no-conditions, r=brson
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.

While sounding nice, conditions ended up having some unforseen shortcomings:

* Actually handling an error has some very awkward syntax:

        let mut result = None;                                        
        let mut answer = None;                                        
        io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| { 
            answer = Some(some_io_operation());                       
        });                                                           
        match result {                                                
            Some(err) => { /* hit an I/O error */ }                   
            None => {                                                 
                let answer = answer.unwrap();                         
                /* deal with the result of I/O */                     
            }                                                         
        }                                                             

  This pattern can certainly use functions like io::result, but at its core
  actually handling conditions is fairly difficult

* The "zero value" of a function is often confusing. One of the main ideas
  behind using conditions was to change the signature of I/O functions. Instead
  of read_be_u32() returning a result, it returned a u32. Errors were notified
  via a condition, and if you caught the condition you understood that the "zero
  value" returned is actually a garbage value. These zero values are often
  difficult to understand, however.

  One case of this is the read_bytes() function. The function takes an integer
  length of the amount of bytes to read, and returns an array of that size. The
  array may actually be shorter, however, if an error occurred.

  Another case is fs::stat(). The theoretical "zero value" is a blank stat
  struct, but it's a little awkward to create and return a zero'd out stat
  struct on a call to stat().

  In general, the return value of functions that can raise error are much more
  natural when using a Result as opposed to an always-usable zero-value.

* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
  is as simple as calling read() and write(), but using conditions imposed the
  restriction that a rust local task was required if you wanted to catch errors
  with I/O. While certainly an surmountable difficulty, this was always a bit of
  a thorn in the side of conditions.

* Functions raising conditions are not always clear that they are raising
  conditions. This suffers a similar problem to exceptions where you don't
  actually know whether a function raises a condition or not. The documentation
  likely explains, but if someone retroactively adds a condition to a function
  there's nothing forcing upstream users to acknowledge a new point of task
  failure.

* Libaries using I/O are not guaranteed to correctly raise on conditions when an
  error occurs. In developing various I/O libraries, it's much easier to just
  return `None` from a read rather than raising an error. The silent contract of
  "don't raise on EOF" was a little difficult to understand and threw a wrench
  into the answer of the question "when do I raise a condition?"

Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.

A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.

Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.

Closes #9795
Closes #8968
2014-02-06 17:11:33 -08:00
Alex Crichton
454882dcb7 Remove std::condition
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.

While sounding nice, conditions ended up having some unforseen shortcomings:

* Actually handling an error has some very awkward syntax:

    let mut result = None;
    let mut answer = None;
    io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
        answer = Some(some_io_operation());
    });
    match result {
        Some(err) => { /* hit an I/O error */ }
        None => {
            let answer = answer.unwrap();
            /* deal with the result of I/O */
        }
    }

  This pattern can certainly use functions like io::result, but at its core
  actually handling conditions is fairly difficult

* The "zero value" of a function is often confusing. One of the main ideas
  behind using conditions was to change the signature of I/O functions. Instead
  of read_be_u32() returning a result, it returned a u32. Errors were notified
  via a condition, and if you caught the condition you understood that the "zero
  value" returned is actually a garbage value. These zero values are often
  difficult to understand, however.

  One case of this is the read_bytes() function. The function takes an integer
  length of the amount of bytes to read, and returns an array of that size. The
  array may actually be shorter, however, if an error occurred.

  Another case is fs::stat(). The theoretical "zero value" is a blank stat
  struct, but it's a little awkward to create and return a zero'd out stat
  struct on a call to stat().

  In general, the return value of functions that can raise error are much more
  natural when using a Result as opposed to an always-usable zero-value.

* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
  is as simple as calling read() and write(), but using conditions imposed the
  restriction that a rust local task was required if you wanted to catch errors
  with I/O. While certainly an surmountable difficulty, this was always a bit of
  a thorn in the side of conditions.

* Functions raising conditions are not always clear that they are raising
  conditions. This suffers a similar problem to exceptions where you don't
  actually know whether a function raises a condition or not. The documentation
  likely explains, but if someone retroactively adds a condition to a function
  there's nothing forcing upstream users to acknowledge a new point of task
  failure.

* Libaries using I/O are not guaranteed to correctly raise on conditions when an
  error occurs. In developing various I/O libraries, it's much easier to just
  return `None` from a read rather than raising an error. The silent contract of
  "don't raise on EOF" was a little difficult to understand and threw a wrench
  into the answer of the question "when do I raise a condition?"

Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.

A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.

Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.

Closes #9795
Closes #8968
2014-02-06 15:48:56 -08:00
bors
c13a929d58 auto merge of #12020 : alexcrichton/rust/output-flags, r=brson
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:

* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]

The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.

The new logic for files that rustc emits is as follows:

1. Output types are dictated by the --emit flag. The default value is
   --emit=link, and this option can be passed multiple times and have all options
   stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
   attribute. The flags can be passed many times and stack with the crate
   attribute.
3. If the -o flag is specified, and only one output type is specified, the
   output will be emitted at this location. If more than one output type is
   specified, then the filename of -o is ignored, and all output goes in the
   directory that -o specifies. The -o option always ignores the --out-dir
   option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the directory of
   the crate file.
6. When multiple output types are specified, the filestem of all output is the
   same as the name of the CrateId (derived from a crate attribute or from the
   filestem of the crate file).

Closes #7791
Closes #11056
Closes #11667
2014-02-06 12:41:30 -08:00
Alex Crichton
6e7968b10a Redesign output flags for rustc
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:

* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]

The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.

The new logic for files that rustc emits is as follows:

1. Output types are dictated by the --emit flag. The default value is
   --emit=link, and this option can be passed multiple times and have all
   options stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
   attribute. The flags can be passed many times and stack with the crate
   attribute.
3. If the -o flag is specified, and only one output type is specified, the
   output will be emitted at this location. If more than one output type is
   specified, then the filename of -o is ignored, and all output goes in the
   directory that -o specifies. The -o option always ignores the --out-dir
   option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the current
   directory of the process.
6. When multiple output types are specified, the filestem of all output is the
   same as the name of the CrateId (derived from a crate attribute or from the
   filestem of the crate file).

Closes #7791
Closes #11056
Closes #11667
2014-02-06 11:14:13 -08:00
Arcterus
9752c63035 Move getopts out of extra 2014-02-06 10:00:17 -08:00
Jeff Olson
b8852e89ce pull extra::{serialize, ebml} into a separate libserialize crate
- `extra::json` didn't make the cut, because of `extra::json` required
   dep on `extra::TreeMap`. If/when `extra::TreeMap` moves out of `extra`,
   then `extra::json` could move into `serialize`
- `libextra`, `libsyntax` and `librustc` depend on the newly created
  `libserialize`
- The extensions to various `extra` types like `DList`, `RingBuf`, `TreeMap`
  and `TreeSet` for `Encodable`/`Decodable` were moved into the respective
  modules in `extra`
- There is some trickery, evident in `src/libextra/lib.rs` where a stub
  of `extra::serialize` is set up (in `src/libextra/serialize.rs`) for
  use in the stage0 build, where the snapshot rustc is still making
  deriving for `Encodable` and `Decodable` point at extra. Big props to
  @huonw for help working out the re-export solution for this

extra: inline extra::serialize stub

fix stuff clobbered in rebase + don't reexport serialize::serialize

no more globs in libserialize

syntax: fix import of libserialize traits

librustc: fix bad imports in encoder/decoder

add serialize dep to librustdoc

fix failing run-pass tests w/ serialize dep

adjust uuid dep

more rebase de-clobbering for libserialize

fixing tests, pushing libextra dep into cfg(test)

fix doc code in extra::json

adjust index.md links to serialize and uuid library
2014-02-05 10:38:22 -08:00
JeremyLetang
dd21a51d29 move concurrent stuff from libextra to libsync 2014-02-05 11:56:04 -05:00
bors
4509b49451 auto merge of #12018 : alexcrichton/rust/triage, r=sfackler
Mostly just test suite modifications.
2014-02-04 21:46:35 -08:00
Alex Crichton
50bdeb9a34 Run all target crate tests on the windows/try bots
Previously, the check-fast and check-lite test suites weren't picking up all
target crates, rather just std/extra. In order to ensure that all of our crates
work on windows, I've modified these rules to build the test suites for all
TARGET_CRATES members. Note that this still excludes rustc/syntax/rustdoc.
2014-02-04 18:05:13 -08:00
Birunthan Mohanathas
f8afc9a5c1 extra: Move uuid to libuuid
cc #8784
2014-02-04 06:44:02 +02:00
OGINO Masanori
fdb820a1be Move semver out of libextra.
Done as a part of #8784.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
2014-02-03 17:18:27 +09:00
xales
51260f69cd Move term, terminfo out of extra.
cc #8784
2014-02-02 18:35:35 -05:00
Alex Crichton
22a421fa02 Rewrite the doc makefile for doc => src/doc
This continues to generate all documentation into doc, but it now looks for
source files in src/doc

Closes #11860
Closes #11970
2014-02-02 10:59:27 -08:00
Alex Crichton
91882a4c56 Remove VPATH usage in Makefiles
This is just messing up all the doc dependencies because of such similar
directory names and file names.

Closes #11422
2014-02-02 10:59:14 -08:00
Corey Richardson
25fe2cadb1 Remove rustpkg.
I'm sorry :'(

Closes #11859
2014-02-02 03:08:56 -05:00
bors
1e23c5c051 auto merge of #11879 : thestinger/rust/frame-pointer, r=alexcrichton
This is still used for Rust code (`Options.NoFramePointerElim = true`).
2014-01-29 13:36:40 -08:00
bors
87004db113 auto merge of #11867 : dmanescu/rust/8784-arena-glob, r=huonw
In line with the dissolution of libextra - #8784 - this moves arena and glob into
their own respective modules. Updates .gitignore with the entries
doc/{arena,glob} in accordance.
2014-01-29 06:26:38 -08:00
bors
1d80a9a0f6 auto merge of #11903 : alexcrichton/rust/android-test-deps, r=huonw
This changes android testing to upload *all* target crates rather than just a
select subset. This should unblock #11867 which is introducing a libglob
dependency in testing.
2014-01-29 01:06:41 -08:00
Alex Crichton
55280598a8 Fix android test deps
This changes android testing to upload *all* target crates rather than just a
select subset. This should unblock #11867 which is introducing a libglob
dependency in testing.
2014-01-29 00:16:32 -08:00
David Manescu
93398d16ec extra: move glob to libglob
In line with the dissolution of libextra - moves glob to its own library libglob.
Changes based on PR #11787. Updates .gitignore to ignore doc/glob.
2014-01-29 17:23:28 +11:00
David Manescu
4d0d3da9e4 extra: move arena to libarena
In line with the dissolution of libextra - #8784 - moves arena to its own library libarena.
Changes based on PR #11787. Updates .gitignore to ignore doc/arena.
2014-01-29 13:54:38 +11:00
Alex Crichton
20d6a8e0af Add a missing backslash to a makefile
Closes #11874
2014-01-28 09:17:06 -08:00
Daniel Micay
17c42db6d1 mk: remove -fno-omit-frame-pointer
This is still used for Rust code (`Options.NoFramePointerElim = true`).
2014-01-28 09:31:59 -05:00
Alex Crichton
0d38e1f9c1 Depend on libnative when testing
The stdtest binary uses both libnative and libgreen to test the two
implementations

Closes #11843
2014-01-27 09:16:55 -08:00
bors
74fedf325a auto merge of #11787 : alexcrichton/rust/refactor, r=brson
It was decided a long, long time ago that libextra should not exist, but rather its modules should be split out into smaller independent libraries maintained outside of the compiler itself. The theory was to use `rustpkg` to manage dependencies in order to move everything out of the compiler, but maintain an ease of usability.

Sadly, the work on `rustpkg` isn't making progress as quickly as expected, but the need for dissolving libextra is becoming more and more pressing. Because of this, we've thought that a good interim solution would be to simply package more libraries with the rust distribution itself. Instead of dissolving libextra into libraries outside of the mozilla/rust repo, we can dissolve libraries into the mozilla/rust repo for now.

Work on this has been excruciatingly painful in the past because the makefiles are completely opaque to all but a few. Adding a new library involved adding about 100 lines spread out across 8 files (incredibly error prone). The first commit of this pull request targets this pain point. It does not rewrite the build system, but rather refactors large portions of it. Afterwards, adding a new library is as simple as modifying 2 lines (easy, right?). The build system automatically keeps track of dependencies between crates (rust *and* native), promotes binaries between stages, tracks dependencies of installed tools, etc, etc.

With this newfound buildsystem power, I chose the `extra::flate` module as the first candidate for removal from libextra. While a small module, this module is relative complex in that is has a C dependency and the compiler requires it (messing with the dependency graph a bit). Albeit I modified more than 2 lines of makefiles to accomodate libflate (the native dependency required 2 extra lines of modifications), but the removal process was easy to do and straightforward.

---

Testing-wise, I've cross-compiled, run tests, built some docs, installed, uninstalled, etc. I'm still working out a few kinks, and I'm sure that there's gonna be built system issues after this, but it should be working well for basic use!

cc #8784
2014-01-26 16:46:34 -08:00
Alex Crichton
cdfdc1eb6b Move extra::flate to libflate
This is hopefully the beginning of the long-awaited dissolution of libextra.
Using the newly created build infrastructure for building libraries, I decided
to move the first module out of libextra.

While not being a particularly meaty module in and of itself, the flate module
is required by rustc and additionally has a native C dependency. I was able to
very easily split out the C dependency from rustrt, update librustc, and
magically everything gets installed to the right locations and built
automatically.

This is meant to be a proof-of-concept commit to how easy it is to remove
modules from libextra now. I didn't put any effort into modernizing the
interface of libflate or updating it other than to remove the one glob import it
had.
2014-01-26 15:42:15 -08:00
Salem Talha
cc61fc0994 Removed all instances of XXX in preparation for relaxing of FIXME rule 2014-01-26 14:42:53 -05:00
Alex Crichton
2611483894 Refactor the build system for easily adding crates
Before this patch, if you wanted to add a crate to the build system you had to
change about 100 lines across 8 separate makefiles. This is highly error prone
and opaque to all but a few. This refactoring is targeted at consolidating this
effort so adding a new crate adds one line in one file in a way that everyone
can understand it.
2014-01-26 00:53:41 -08:00
bors
f3f2e697d8 auto merge of #11619 : adridu59/rust/patch-md, r=cmr
Noticeably necroes #10892.
Also closes #11559.

r? @alexcrichton
2014-01-18 09:01:46 -08:00
Alex Crichton
bd469341eb test: Add the ability to force a host target
The new macro loading infrastructure needs the ability to force a
procedural-macro crate to be built with the host architecture rather than the
target architecture (because the compiler is just about to dlopen it).
2014-01-17 11:13:22 -08:00
Adrien Tétar
b2cac497e8 doc: fix version stamp for TeX files
This fixes a regression introduced in
3d57b240ab.
2014-01-17 19:38:51 +01:00
Vadim Chugunov
62fbd00bed Only build LLVM tools Rust needs. 2014-01-15 17:47:48 -08:00
bors
dd8b011319 auto merge of #11521 : dguenther/rust/hide_libdir_relative, r=alexcrichton
Renamed `LIBDIR_RELATIVE` to `CFG_LIBDIR_RELATIVE`. It's not a configurable variable, but it looks out of place without the `CFG_` prefix.

Fixes #11420
2014-01-14 15:11:30 -08:00
Derek Guenther
a599d897fc Renamed LIBDIR_RELATIVE to CFG_LIBDIR_RELATIVE 2014-01-14 15:52:57 -06:00
bors
77eeddaa48 auto merge of #11501 : alexcrichton/rust/dox, r=brson
The official documentation sorely needs an explanation of the rust runtime and what it is exactly, and I want this guide to provide that information.

I'm unsure of whether I've been too light on some topics while too heavy on others. I also feel like a few things are still missing. As always, feedback is appreciated, especially about things you'd like to see written about!
2014-01-13 23:26:36 -08:00
Alex Crichton
289ba105ae dox: Write a guide to the rust runtime 2014-01-13 23:22:07 -08:00
Brian Anderson
279366a0b2 mk: Make TESTNAME and VERBOSE work with android. Closes #10957 2014-01-13 19:45:37 -08:00
Kevin Ballard
110e5dd1ac doc: build the docs for librustpkg 2014-01-11 19:13:59 -08:00
Adrien Tétar
72794094a1 Trim src/ README, bring back version_info everywhere 2014-01-11 19:55:24 +01:00
bors
01794cc993 auto merge of #11461 : alexcrichton/rust/rustdoc-fixes, r=brson
See the commits.
2014-01-11 02:41:23 -08:00
Alex Crichton
b1eaeb5561 doc: build the docs for librustuv
Closes #11444
2014-01-10 15:12:06 -08:00
Ted Horst
0d4c51e1d1 fix uninstall target with configurable rustlib directory 2014-01-10 13:45:41 -06:00
Alex Crichton
f2a86a2da6 Register new snapshots 2014-01-09 09:18:59 -08:00
bors
f3a8baafbe auto merge of #11407 : alexcrichton/rust/fix-snap, r=brson
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler
already knows about the rustc => rustlib change, so we need to not add the extra
flag if it's a stage0 version of a target from a stage1 of another target.
2014-01-08 08:46:33 -08:00
Alex Crichton
004dae6abd Fix the snapshot and cross compilation
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler
already knows about the rustc => rustlib change, so we need to not add the extra
flag if it's a stage0 version of a target from a stage1 of another target.
2014-01-08 08:16:48 -08:00
Brian Anderson
77ec04487b mk: Start testing the cheatsheet 2014-01-07 17:01:07 -08:00
bors
aa1839bd69 auto merge of #11364 : brson/rust/docs, r=alexcrichton
This reorganizes the documentation index to be more focused on the in-tree docs, and to clean up the style, and it also adds @steveklabnik's pointer guide.
2014-01-07 15:46:38 -08:00
Jan Niklas Hasse
116773a4eb Make CFG_LIBDIR configurable. Fixes #5223 2014-01-07 17:51:15 +01:00
bors
777f1e8d24 auto merge of #11355 : alexcrichton/rust/read-waits-forever, r=brson
All the fun is down below.
2014-01-06 23:36:46 -08:00