Commit Graph

1070 Commits

Author SHA1 Message Date
Liigo Zhuang
53b9d1a324 move extra::test to libtest 2014-02-20 16:03:58 +08:00
Virgile Andreani
ece12d8da6 mk: Fix the regexp of SHOW_DOCS
The tag marks were missing, and `make tips` didn't work.
2014-02-18 11:53:23 +01:00
Derek Guenther
b609d57b02 Added more scripts to tidy check 2014-02-17 10:36:47 -06:00
bors
57d273f65e auto merge of #12284 : brson/rust/install, r=alexcrichton
Work toward #9876.

This adds `prepare.mk`, which is simply a more heavily-parameterized `install.mk`, then uses `prepare` to implement both `install` and the windows installer (`dist`). Smoke tested on both Linux and Windows.
2014-02-17 03:26:51 -08:00
Brian Anderson
2b64cb294c Address review feedback 2014-02-16 17:36:43 -08:00
Brian Anderson
58678dc229 mk: Fix typo, NO_MAKEFILE_DEPS -> NO_MKFILE_DEPS 2014-02-15 23:12:56 -08:00
Brian Anderson
109673f368 mk: Remove check-notidy, check-full, check-test
Mostly useless
2014-02-15 23:11:56 -08:00
Luqman Aden
615536a265 mk: Remove old flags to llc for arm. 2014-02-15 20:08:33 -05:00
Brian Anderson
508cb29dc4 mk: Base the windows dist target on prepare.mk 2014-02-15 14:18:00 -08:00
Brian Anderson
8f2bee2117 mk: Fix a dist bug
Fallout from moving doc/ to src/doc
2014-02-15 14:18:00 -08:00
Brian Anderson
9cd96e4f02 mk: Base the install target on prepare.mk 2014-02-15 14:18:00 -08:00
Brian Anderson
4cd8bdc969 mk: Add prepare.mk
This is a slightly more generic rewrite of install.mk. Currently
used for nothing, but we'll base all the binary distributables off it.
2014-02-15 14:17:57 -08:00
Brian Anderson
8d4b675ced mk: Address review feedback 2014-02-14 19:17:50 -08:00
Brian Anderson
24915c84e0 mk: Move version info to top of main.mk
Just so it's easier to find.
2014-02-14 17:45:54 -08:00
Brian Anderson
334af011f0 mk: Improve build system help commands 2014-02-14 17:45:54 -08:00
Brian Anderson
ab17f445fe mk: Add NO_MKFILE_DEPS for turning off rebuild from makefile changes 2014-02-14 17:45:54 -08:00
Brian Anderson
2852fea61e mk: Move most of Makefile.in to .mk files
Because the build system treats Makefile.in and the .mk files slightly
differently (.in is copied, .mk are included), this makes the system
more uniform. Fewer build system changes will require a complete
reconfigure.
2014-02-14 17:45:54 -08:00
bors
3f717bbe96 auto merge of #12267 : alexcrichton/rust/rollup, r=alexcrichton
The last commit has the closed PRs
2014-02-14 12:21:51 -08:00
Alex Crichton
8694fd1e96 Add MKFILE_DEPS to compiler-rt target
Currently when you run `make -jN` it's likely that you'll remove compiler-rt and
then it won't get cp'd back into the right place. I believe the reason for this
is that the compiler-rt library target never got updated so make decided it
never needed to copy the files back into place. The files were all there at the
beginning of `make`, but then we may clean out the stage0 versions if we unzip
the snapshot again.
2014-02-14 10:46:19 -08:00
HeroesGrave
11b2515f0f Removed libextra dependency from libsyntax. 2014-02-14 07:47:31 -08:00
bors
92c5738aae auto merge of #12207 : alexcrichton/rust/up-llvm, r=sfackler
Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.

This also introduces a new commit on top of our stack of patches to fix a mingw32 build issue. I have submitted the patch upstream: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140210/204653.html

I verified that this builds on the try bots, which amazes me because I think that c++11 is turned on now, but I guess we're still lucky!

Closes #10613 (pcwalton's patch landed)
Closes #11992 (llvm has removed these options)
2014-02-14 07:26:40 -08:00
Alex Crichton
804955f79a Upgrade LLVM
Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.
2014-02-14 07:22:49 -08:00
bors
d40b537405 auto merge of #12192 : luqmana/rust/fix-cross, r=alexcrichton
Fix some fall out from the big command line option changes.
2014-02-14 01:41:46 -08:00
Alex Crichton
301ff0c2df Remove two allocations from spawning a green task
Two unfortunate allocations were wrapping a proc() in a proc() with
GreenTask::build_start_wrapper, and then boxing this proc in a ~proc() inside of
Context::new(). Both of these allocations were a direct result from two
conditions:

1. The Context::new() function has a nice api of taking a procedure argument to
   start up a new context with. This inherently required an allocation by
   build_start_wrapper because extra code needed to be run around the edges of a
   user-provided proc() for a new task.

2. The initial bootstrap code only understood how to pass one argument to the
   next function. By modifying the assembly and entry points to understand more
   than one argument, more information is passed through in registers instead of
   allocating a pointer-sized context.

This is sadly where I end up throwing mips under a bus because I have no idea
what's going on in the mips context switching code and don't know how to modify
it.

Closes #7767
cc #11389
2014-02-13 20:31:17 -08:00
Luqman Aden
ffdda22aa2 mk: Fix non-android cross builds. 2014-02-13 18:11:23 -05:00
Huon Wilson
44e6883d14 mk: make NO_REBUILD more forceful and more general.
Previously crates like `green` and `native` would still depend on their
parents when running `make check-stage2-green NO_REBUILD=1`, this
ensures that they only depend on their source files.

Also, apply NO_REBUILD to the crate doc tests, so, for example,
`check-stage2-doc-std` will use an already compiled `rustdoc` directly.
2014-02-13 12:54:01 -08:00
Alex Crichton
745aa7482a Include compiler-rt in the distribution tarballs 2014-02-13 12:50:25 -08:00
Vadim Chugunov
b7651325eb Build compiler-rt and link it to all crates, similarly to morestack. 2014-02-11 15:59:59 -08:00
Florian Hahn
f62460c1f5 Change xfail directives in compiletests to ignore, closes #11363 2014-02-11 18:23:20 +01:00
Felix S. Klock II
d2d1129ad0 Factoring bigint, rational, and complex out of libextra into libnum.
Removed use of globs present in earlier versions of modules.

Fix tutorial.md to reflect `extra::rational` ==> `num::rational`.
2014-02-11 10:39:15 +01:00
Alex Crichton
e25701132c Move fourcc to HOST_CRATES
It depends on libsyntax, which is a host crate, so it can't be in the target
crates section.
2014-02-10 11:51:06 -08:00
bors
d440a569bb auto merge of #12084 : alexcrichton/rust/codegen-opts, r=cmr
Move them all behind a new -C switch. This migrates some -Z flags and some
top-level flags behind this -C codegen option.

The -C flag takes values of the form "-C name=value" where the "=value" is
optional for some flags.

Flags affected:

* --llvm-args           => -C llvm-args
* --passes              => -C passes
* --ar                  => -C ar
* --linker              => -C linker
* --link-args           => -C link-args
* --target-cpu          => -C target-cpu
* --target-feature      => -C target-fature
* --android-cross-path  => -C android-cross-path
* --save-temps          => -C save-temps
* --no-rpath            => -C no-rpath
* -Z no-prepopulate     => -C no-prepopulate-passes
* -Z no-vectorize-loops => -C no-vectorize-loops
* -Z no-vectorize-slp   => -C no-vectorize-slp
* -Z soft-float         => -C soft-float
* -Z gen-crate-map      => -C gen-crate-map
* -Z prefer-dynamic     => -C prefer-dynamic
* -Z no-integrated-as   => -C no-integrated-as

As a bonus, this also promotes the -Z extra-debug-info flag to a first class -g
or --debuginfo flag.

* -Z debug-info         => removed
* -Z extra-debug-info   => -g or --debuginfo

Closes #9770
Closes #12000
2014-02-10 01:26:24 -08:00
Alex Crichton
071ee96277 Consolidate codegen-related compiler flags
Move them all behind a new -C switch. This migrates some -Z flags and some
top-level flags behind this -C codegen option.

The -C flag takes values of the form "-C name=value" where the "=value" is
optional for some flags.

Flags affected:

* --llvm-args           => -C llvm-args
* --passes              => -C passes
* --ar                  => -C ar
* --linker              => -C linker
* --link-args           => -C link-args
* --target-cpu          => -C target-cpu
* --target-feature      => -C target-fature
* --android-cross-path  => -C android-cross-path
* --save-temps          => -C save-temps
* --no-rpath            => -C no-rpath
* -Z no-prepopulate     => -C no-prepopulate-passes
* -Z no-vectorize-loops => -C no-vectorize-loops
* -Z no-vectorize-slp   => -C no-vectorize-slp
* -Z soft-float         => -C soft-float
* -Z gen-crate-map      => -C gen-crate-map
* -Z prefer-dynamic     => -C prefer-dynamic
* -Z no-integrated-as   => -C no-integrated-as

As a bonus, this also promotes the -Z extra-debug-info flag to a first class -g
or --debuginfo flag.

* -Z debug-info         => removed
* -Z extra-debug-info   => -g or --debuginfo

Closes #9770
Closes #12000
2014-02-10 00:50:39 -08:00
Brian Anderson
3062d0f6bb mk: Replace 'compile_and_link' with 'oxidize' 2014-02-09 02:42:28 -08:00
Derek Guenther
97078d43b2 Converted fourcc! to loadable syntax extension 2014-02-08 23:40:17 -06:00
bors
b66ec3483b auto merge of #12114 : brson/rust/faqs, r=cmr
These are ancient. I removed a bunch of questions that are less relevant - or completely unrelevant, updated other entries, and removed things that are already better expressed elsewhere.
2014-02-08 20:01:27 -08:00
Luca Bruno
51b74c41ff make: update dist target after libextra split
libextra is currently being split into several crates. This commit adds
them all to the dist target in order to have them in the final tarballs.

Signed-off-by: Luca Bruno <lucab@debian.org>
2014-02-08 21:32:43 +01:00
Luca Bruno
99cdabab00 make: update dist target for renamed files
src/README.txt has been renamed in a30d61b05a, make dist is
thus failing as unable to find it.
This commit makes the dist target working again.

Signed-off-by: Luca Bruno <lucab@debian.org>
2014-02-08 14:36:18 +01:00
Brian Anderson
30dcc8285b doc: Modernize FAQs just slightly 2014-02-08 00:38:00 -08:00
bors
b2c1a81649 auto merge of #12099 : alexcrichton/rust/rpath-tests, r=thestinger
This way when you disable rpaths you can still run `make check`
2014-02-07 22:01:30 -08:00
bors
29e500db8a auto merge of #12094 : adridu59/rust/licensing, r=brson
Closes #12069.

cc @brson
2014-02-07 16:16:35 -08:00
Alex Crichton
28b72cdae4 Set the LD_LIBRARY_PATH when running tests
This way when you disable rpaths you can still run `make check`
2014-02-07 16:04:57 -08:00
Adrien Tétar
ec2f047aa9 doc: add license information for gen. files 2014-02-07 20:50:15 +01:00
Derek Guenther
730bdb6403 Added tests to make tidy 2014-02-07 12:49:24 -06:00
bors
21b856d2dc auto merge of #12010 : HeroesGrave/rust/libcollection, r=alexcrichton
Part of #8784

Changes:
- Everything labeled under collections in libextra has been moved into a new crate 'libcollection'.
- Renamed container.rs to deque.rs, since it was no longer 'container traits for extra', just a deque trait.
- Crates that depend on the collections have been updated and dependencies sorted.
- I think I changed all the imports in the tests to make sure it works. I'm not entirely sure, as near the end of the tests there was yet another `use` that I forgot to change, and when I went to try again, it started rebuilding everything, which I don't currently have time for. 

There will probably be incompatibility between this and the other pull requests that are splitting up libextra. I'm happy to rebase once those have been merged.

The tests I didn't get to run should pass. But I can redo them another time if they don't.
2014-02-06 23:46:35 -08:00
HeroesGrave
d81bb441da moved collections from libextra into libcollections 2014-02-07 19:49:26 +13:00
bors
a27934c555 auto merge of #12076 : alexcrichton/rust/rpath-makefile-dep, r=thestinger
The rpath variable should only be used when executing commands, if it leaks into
a dependency list is causes havoc with the dependencies.
2014-02-06 19:16:34 -08: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
80920da6b9 Don't include rpath lines in dependency lists
The rpath variable should only be used when executing commands, if it leaks into
a dependency list is causes havoc with the dependencies.
2014-02-06 16:33:41 -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