Commit Graph

26351 Commits

Author SHA1 Message Date
Huon Wilson
1dd1880121 syntax: convert the lexer to use Option<char> over transmute(-1).
The transmute was unsound.

There are many instances of .unwrap_or('\x00') for "ignoring" EOF which
either do not make the situation worse than it was (well, actually make
it better, since it's easy to grep for places that don't handle EOF) or
can never ever be read.

Fixes #8971.
2014-02-08 12:13:27 +11:00
Huon Wilson
e7908c0a66 extra::json: remove the use of unsafe char transmutes.
Avoid using -1 as a char sentinel, when Option<char> is the perfect
thing.
2014-02-08 12:13:27 +11:00
Daniel Micay
940d1ae2f3 remove type descriptors from proc and @T
This also drops support for the managed pointer POISON_ON_FREE feature
as it's not worth adding back the support for it. After a snapshot, the
leftovers can be removed.
2014-02-07 20:08:35 -05: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
bors
1fd2d77860 auto merge of #12029 : zkamsler/rust/merge-sort-allocations, r=huonw
This pull request:
1) Changes the initial insertion sort to be in-place, and defers allocation of working set until merge is needed.
2) Increases the increases the maximum run length to use insertion sort for from 8 to 32 elements. This increases the size of vectors that will not allocate, and reduces the number of merge passes by two. It seemed to be the sweet spot in the benchmarks that I ran.

Here are the results of some benchmarks. Note that they are sorting u64s, so types that are more expensive to compare or copy may have different behaviors.
Before changes:
```
test vec::bench::sort_random_large      bench:    719753 ns/iter (+/- 130173) = 111 MB/s
test vec::bench::sort_random_medium     bench:      4726 ns/iter (+/- 742) = 169 MB/s
test vec::bench::sort_random_small      bench:       344 ns/iter (+/- 76) = 116 MB/s
test vec::bench::sort_sorted            bench:    437244 ns/iter (+/- 70043) = 182 MB/s
```

Deferred allocation (8 element insertion sort):
```
test vec::bench::sort_random_large      bench:    702630 ns/iter (+/- 88158) = 113 MB/s
test vec::bench::sort_random_medium     bench:      4529 ns/iter (+/- 497) = 176 MB/s
test vec::bench::sort_random_small      bench:       185 ns/iter (+/- 49) = 216 MB/s
test vec::bench::sort_sorted            bench:    425853 ns/iter (+/- 60907) = 187 MB/s
```

Deferred allocation (16 element insertion sort):
```
test vec::bench::sort_random_large      bench:    692783 ns/iter (+/- 165837) = 115 MB/s
test vec::bench::sort_random_medium     bench:      4434 ns/iter (+/- 722) = 180 MB/s
test vec::bench::sort_random_small      bench:       187 ns/iter (+/- 38) = 213 MB/s
test vec::bench::sort_sorted            bench:    393783 ns/iter (+/- 85548) = 203 MB/s
```

Deferred allocation (32 element insertion sort):
```
test vec::bench::sort_random_large      bench:    682556 ns/iter (+/- 131008) = 117 MB/s
test vec::bench::sort_random_medium     bench:      4370 ns/iter (+/- 1369) = 183 MB/s
test vec::bench::sort_random_small      bench:       179 ns/iter (+/- 32) = 223 MB/s
test vec::bench::sort_sorted            bench:    358353 ns/iter (+/- 65423) = 223 MB/s
```

Deferred allocation (64 element insertion sort):
```
test vec::bench::sort_random_large      bench:    712040 ns/iter (+/- 132454) = 112 MB/s
test vec::bench::sort_random_medium     bench:      4425 ns/iter (+/- 784) = 180 MB/s
test vec::bench::sort_random_small      bench:       179 ns/iter (+/- 81) = 223 MB/s
test vec::bench::sort_sorted            bench:    317812 ns/iter (+/- 62675) = 251 MB/s
```

This is the best I could manage with the basic merge sort while keeping the invariant that the original vector must contain each element exactly once when the comparison function is called. If one is not married to a stable sort, an in-place n*log(n) sorting algorithm may have better performance in some cases.

for #12011
cc @huonw
2014-02-07 14:21:30 -08:00
Zach Kamsler
cebe5e8e6b Reduced allocations in merge_sort for short vectors
Added a seperate in-place insertion sort for short vectors.
Increased threshold for insertion short for 8 to 32 elements
for small types and 16 for larger types. Added benchmarks
for sorting larger types.
2014-02-07 17:11:28 -05:00
Brian Anderson
b91caac729 rustc: Remove 'morestack_addr' intrinsic. Unused 2014-02-07 13:21:35 -08:00
bors
7d7a060f8d auto merge of #12073 : alexcrichton/rust/doc-examples, r=cmr
"How do I start in libX" is a common question that I've seen, so I figured
putting the examples in as many places as possible is probably a good idea.
2014-02-07 12:41:35 -08:00
Adrien Tétar
ec2f047aa9 doc: add license information for gen. files 2014-02-07 20:50:15 +01:00
bors
56565eb129 auto merge of #12055 : dguenther/rust/tidy_test, r=alexcrichton
This PR extends the tidy formatting check to rust files in the test folder. To facilitate this, a few flags were added to tidy:

* `xfail-tidy-cr` - Disables the check for CR characters for all following lines in the file
* `xfail-tidy-tab` - Disables the check for tab characters for all following lines in the file
* `xfail-tidy-linelength` - Disables the line length check for all following lines in the file

Checks should not have to be disabled often. I disabled line length checks in `debug-info` tests that use `debugger:` checks, but aside from that, there were relatively few exclusions. Running tidy on all the tests does slow down the formatting check, so it may be worth investigating further optimization.

cc #4534
2014-02-07 11:26:29 -08:00
Derek Guenther
730bdb6403 Added tests to make tidy 2014-02-07 12:49:24 -06:00
Brendan Zabarauskas
8192f5508a Clean up formatting in macros module 2014-02-08 05:39:50 +11:00
bors
ca40da8b55 auto merge of #12075 : chromatic/rust/gh_11983_deglob_std, r=alexcrichton
This replaces the imports from the prelude with the re-exported symbols.
2014-02-07 10:11:29 -08:00
chromatic
b91b6a746b Cleaned up imports per coding standards.
No functional changes; just style.
2014-02-07 09:59:19 -08:00
chromatic
813886b22c Removed prelude::* from libstd files.
This replaces the imports from the prelude with the re-exported symbols.
2014-02-07 09:59:19 -08:00
Brendan Zabarauskas
1e55cae783 Add missing test for unreachable! macro 2014-02-08 04:43:51 +11:00
Brendan Zabarauskas
7e1cfc8893 Add unimplemented! macro 2014-02-08 04:43:39 +11:00
bors
c3ccaacc6c auto merge of #12087 : sanxiyn/rust/show-span, r=huonw 2014-02-07 03:26:34 -08:00
Seo Sanghyeon
e5463b996c Add comments to span debugger 2014-02-07 20:13:07 +09:00
Seo Sanghyeon
5109d1adce Correct span for ExprFnBlock, ExprMethodCall, ExprParen 2014-02-07 19:52:12 +09:00
Seo Sanghyeon
104002be6f Span debugger 2014-02-07 19:50:07 +09:00
bors
14cb4be6e9 auto merge of #12083 : bjz/rust/semver, r=huonw 2014-02-07 02:11:30 -08:00
bors
36f1b38f80 auto merge of #12062 : kballard/rust/from_utf8_lossy, r=huonw
`from_utf8_lossy()` takes a byte vector and produces a `~str`, converting
any invalid UTF-8 sequence into the U+FFFD REPLACEMENT CHARACTER.

The replacement follows the guidelines in §5.22 Best Practice for U+FFFD
Substitution from the Unicode Standard (Version 6.2)[1], which also
matches the WHATWG rules for utf-8 decoding[2].

[1]: http://www.unicode.org/versions/Unicode6.2.0/ch05.pdf
[2]: http://encoding.spec.whatwg.org/#utf-8

Closes #9516.
2014-02-07 00:56:31 -08: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
Kevin Ballard
544cb42d7a Hoist path::Display on top of from_utf8_lossy() 2014-02-06 23:44:26 -08:00
Kevin Ballard
b0b89a57d5 Add new function str::from_utf8_lossy()
from_utf8_lossy() takes a byte vector and produces a ~str, converting
any invalid UTF-8 sequence into the U+FFFD REPLACEMENT CHARACTER.

The replacement follows the guidelines in §5.22 Best Practice for U+FFFD
Substitution from the Unicode Standard (Version 6.2)[1], which also
matches the WHATWG rules for utf-8 decoding[2].

[1]: http://www.unicode.org/versions/Unicode6.2.0/ch05.pdf
[2]: http://encoding.spec.whatwg.org/#utf-8
2014-02-06 23:44:26 -08:00
Brendan Zabarauskas
aa829c2904 Implement std::fmt::Show for semver::{Identifier, Version} 2014-02-07 18:03:06 +11:00
HeroesGrave
d81bb441da moved collections from libextra into libcollections 2014-02-07 19:49:26 +13:00
bors
55f53f553a auto merge of #12078 : colemickens/rust/patch-2, r=alexcrichton 2014-02-06 22:31:33 -08:00
Brendan Zabarauskas
78cb1e2ab0 Make semver::Version fields public 2014-02-07 17:19:21 +11:00
bors
396ef9352e auto merge of #12077 : colemickens/rust/patch-1, r=alexcrichton 2014-02-06 21:11:34 -08: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
1508b6e953 Add some doc examples to lib{green,native}
"How do I start in libX" is a common question that I've seen, so I figured
putting the examples in as many places as possible is probably a good idea.
2014-02-06 16:45:22 -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
Cole Mickens
ee608cb935 Update link_name=... -> link(name=... 2014-02-06 15:54:25 -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
Cole Mickens
4352a8d604 Fix a dead URL 2014-02-06 15:48:15 -08:00
bors
6d27b013c6 auto merge of #12030 : eddyb/rust/kill-at-self-and-trait, r=cmr 2014-02-06 14:51:30 -08:00
Eduard Burtescu
b2d30b72bf Removed @self and @Trait. 2014-02-07 00:38:33 +02: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
bors
680925e258 auto merge of #12007 : Arcterus/rust/libgetopts, r=cmr
Should help towards finishing #8784.
2014-02-06 11:16:33 -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
968ce53dff getopts: fixed a failing test 2014-02-06 10:04:26 -08:00
Arcterus
2ce7019b87 getopts: unify tests 2014-02-06 10:04:26 -08:00
Arcterus
c09ca940e5 getopts: replaced base functions with those from group 2014-02-06 10:04:26 -08:00
Arcterus
9752c63035 Move getopts out of extra 2014-02-06 10:00:17 -08:00
bors
66b9c35654 auto merge of #12053 : fhahn/rust/remove-str-in-comment, r=alexcrichton
This tiny pull request updates a comment referring to `@str` which was replaced by `(InternedString,StrStyle)` .

related to #10516
2014-02-06 09:21:31 -08:00
bors
f039d10cf7 auto merge of #12048 : sanxiyn/rust/crate-config, r=alexcrichton 2014-02-06 08:06:33 -08:00