This moves them all into the traits submodule, and delegates Ord
to the TotalOrd instance. It also deletes the stand-alone lt, gt,
ge and le functions.
This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.
Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.
The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.
http://wiki.debian.org/RpathIssuehttps://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.
Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.
The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.
http://wiki.debian.org/RpathIssuehttps://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
Remove all the explicit @mut-fields from CrateContext, though many
fields are still @-ptrs.
This required changing every single function call that explicitly
took a @CrateContext, so I took advantage and changed as many as I
could get away with to &-ptrs or &mut ptrs.
Currently, when calling glue functions, we cast the function to match
the argument type. This interacts very badly with LLVM and breaks
inlining of the glue code.
It's more efficient to use a unified function type for the glue
functions and always cast the function argument instead of the function.
The resulting code for rustc is about 13% faster (measured up to and
including the "trans" pass) and the resulting librustc is about 5%
smaller.
Currently, when calling glue functions, we cast the function to match
the argument type. This interacts very badly with LLVM and breaks
inlining of the glue code.
It's more efficient to use a unified function type for the glue
functions and always cast the function argument instead of the function.
The resulting code for rustc is about 13% faster (measured up to and
including the "trans" pass) and the resulting librustc is about 5%
smaller.
r? @graydon Automate more tests described in the commands.txt file,
and add infrastructure for running them. Right now, tests shell
out to call rustpkg. This is not ideal.
Goes part of the way towards addressing #5683
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
r? @brson
links to issues: #7065 the race that's fixed; #7066 the perf improvement I added. There are also some minor cleanup commits here.
To measure the performance improvement from replacing the exclusive with an atomic uint, I edited the ```msgsend-ring-rw-arcs``` bench test to do a ```write_downgrade``` instead of just a ```write```, so that it stressed the code paths that accessed ```read_count```. (At first I was still using ```write``` and saw no performance difference whatsoever, whoooops.)
The bench test measures how long it takes to send 1,000,000 messages by using rwarcs to emulate pipes. I also measured the performance difference imposed by the fix to the ```access_lock``` race (which involves taking an extra semaphore in the ```cond.wait()``` path). The net result is that fixing the race imposes a 4% to 5% slowdown, but doing the atomic uint optimization gives a 6% to 8% speedup.
Note that this speedup will be most visible in read- or downgrade-heavy workloads. If an RWARC's only users are writers, the optimization doesn't matter. All the same, I think this more than justifies the extra complexity I mentioned in #7066.
The raw numbers are:
```
with xadd read count
before write_cond fix
4.18 to 4.26 us/message
with write_cond fix
4.35 to 4.39 us/message
with exclusive read count
before write_cond fix
4.41 to 4.47 us/message
with write_cond fix
4.65 to 4.76 us/message
```
Implement conditional support in terminfo, along with a few other related operators.
Fix implementation of non-commutative arithmetic operators.
Remove all known cases of task failure from `terminfo::parm::expand`, and change the method signature.
Fix some other miscellaneous issues.
The code compiles and runs under windows now, but I couldn't look up any
symbol from the current executable (dlopen(NULL)), and calling looked
up external function handles doesn't seem to work correctly under windows.
This un-reverts the reverts of the rusti commits made awhile back. These were reverted for an LLVM failure in rustpkg. I believe that this is not a problem with these commits, but rather that rustc is being used in parallel for rustpkg tests (in-process). This is not working yet (almost! see #7011), so I serialized all the tests to run one after another.
@brson, I'm mainly just guessing as to the cause of the LLVM failures in rustpkg tests. I'm confident that running tests in parallel is more likely to be the problem than those commits I made.
Additionally, this fixes two recently reported issues with rusti.
Automate more tests described in the commands.txt file,
and add infrastructure for running them. Right now, tests shell
out to call rustpkg. This is not ideal.
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
The lookups for these items in external crates currently cause repeated
decoding of the EBML metadata, which is pretty slow. Adding caches to
avoid the repeated decoding reduces the time required for the type
checking of librustc by about 25%.
The lookups for these items in external crates currently cause repeated
decoding of the EBML metadata, which is pretty slow. Adding caches to
avoid the repeated decoding reduces the time required for the type
checking of librustc by about 25%.
Implement the %?, %t, %e, and %; operators. Also implement the %<, %=,
%> operators, without which conditionals aren't very useful.
Fix the order of parameters for the arithmetic operators.
Implement the missing %^ operator.
Replace all potentially-failing operations with Err returns and add
tests.
Remove the Char parameter type; characters are represented as Numbers.
Fix integer constants to work properly when there are multiple constants
in the same capability string.
Tweak loop to use iterators instead of indexing into cap.
This fixes the strange random crashes in compile-fail tests.
This reverts commit 96cd61ad03.
Conflicts:
src/librustc/driver/driver.rs
src/libstd/str.rs
src/libsyntax/ext/quote.rs
Previously, this was not a global call, and so when `#[deriving(Rand)]`
was in any module other than the top-level one, it failed (unless there
was a `use std;` in scope).
Also, fix a minor inconsistency between uints and u32s for this piece
of code.
More descriptive comments can be found throughout the code, but the bulk of this is that it addresses a vast number of issues with the old rusti model.
Closes#6772, #5675, #5469, and #6617
I would appreciate if someone could help out with the Windows code on this pull request. I tried to test it using WINE but I couldn't figure out a way to set that up.
This almost removes the StringRef wrapper, since all strings are
Equiv-alent now. Removes a lot of `/* bad */ copy *`'s, and converts
several things to be &'static str (the lint table and the intrinsics
table).
There are many instances of .to_managed(), unfortunately.
There are now only half-a-dozen or so functions left `std::str` that should be methods.
Highlights:
- `.substr` was removed, since most of the uses of it in the code base were actually incorrect (it had a weird mixing of a byte index and a unicode character count), adding `.slice_chars` if one wants to handle characters, and the normal `.slice` method to handle bytes.
- Code duplication between the two impls for `connect` and `concat` was removed via a new `Str` trait, that is purely designed to allow an explicit -> `&str` conversion (`.as_slice()`)
- Deconfuse the 5 different functions for converting to `[u8]` (3 of which had actually incorrect documentation: implying that they didn't have the null terminator), into 3: `as_bytes` (all strings), `as_bytes_with_null` (`&'static str`, `@str` and `~str`) and `as_bytes_with_null_consume` (`~str`). None of these allocate, unlike the old versions.
(cc @thestinger)
The Str trait collects the various strings types and provides a method
for coercing to a slice, so that functions and impls can be written for
generic types containing strings (e.g. &[~str], &[&str], ...) without
having to write one for each string type (assuming that the impl only
needs a slice).
The confusing mixture of byte index and character count meant that every
use of .substr was incorrect; replaced by slice_chars which only uses
character indices. The old behaviour of `.substr(start, n)` can be emulated
via `.slice_from(start).slice_chars(0, n)`.
This was a lot more painful than just changing `x.each` to `x.iter().advance` . I ran into my old friend #5898 and had to add underscores to some method names as a temporary workaround.
The borrow checker also had other ideas because rvalues aren't handled very well yet so temporary variables had to be added. However, storing the temporary in a variable led to dynamic `@mut` failures, so those had to be wrapped in blocks except where the scope ends immediately.
Anyway, the ugliness will be fixed as the compiler issues are fixed and this change will amount to `for x.each |x|` becoming `for x.iter |x|` and making all the iterator adaptors available.
I dropped the run-pass tests for `old_iter` because there's not much point in fixing a module that's on the way out in the next week or so.
This commit fixes#7022 - I've added an additional check to ensure that
stk is not null before dereferencing it to get it's next element,
assigning NULL if it is itself NULL.
This is a reopening of #6570, and almost fixes#6511.
Note that this doesn't actually enable building a threadsafe LLVM, because that will require an LLVM rebuild which will be bundled with the upgrades in #6713.
What this does do, however, is removes all thread-unsafe usage of LLVM from the compiler.
OS X's terminfo uses the hex representation of the first character of
the terminal name as the directory name.
Ubuntu seems to use /lib/terminfo instead of /usr/share/terminfo, at
least on the one machine I have access to.
