| Age | Commit message (Collapse) | Author | Lines |
|---|
|
With the recently added double word CAS functionality on 32-bit ARM (enabled via
a 64-bit atomic instruction in LLVM IR), without some extra features enabled
LLVM lowers code to function calls which emulate atomic instructions. With the
v7 feature enabled, proper 64-bit CAS instructions are used on 32-bit arm.
I've been told that v7 for arm is what we should have been doing anyway. This is
overridable by providing some other non-empty feature string.
|
|
|
|
|
|
handling
|
|
I believe that this is leading to lots of failures on the bots.
cc #11954
|
|
This is still used for Rust code (`Options.NoFramePointerElim = true`).
|
|
This can almost be fully disabled, as it no longer breaks retrieving a
backtrace on OS X as verified by @alexcrichton. However, it still
breaks retrieving the values of parameters. This should be fixable in
the future via a proper location list...
Closes #7477
|
|
code instead.
|
|
By default, the compiler and libraries are all still built with rpaths, but this
can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc.
cc #5219
|
|
[On 2013-12-06, I wrote to the rust-dev mailing list](https://mail.mozilla.org/pipermail/rust-dev/2013-December/007263.html):
> Subject: Let’s avoid having both foo() and foo_opt()
>
> We have some functions and methods such as [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may succeed and give a result, or fail when the input is invalid.
>
> 1. Sometimes we assume the input is valid and don’t want to deal with the error case. Task failure works nicely.
>
> 2. Sometimes we do want to do something different on invalid input, so returning an `Option<T>` works best.
>
> And so we end up with both `from_utf8` and `from_utf8`. This particular case is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, to cover everything.
>
> Multiplying names like this is just not good design. I’d like to reduce this pattern.
>
> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the Option. I think we should rename every `foo_opt()` function or method to just `foo`, remove the old `foo()` behavior, and tell people (through documentation) to use `foo().unwrap()` if they want it back?
>
> The downsides are that unwrap is more verbose and gives less helpful error messages on task failure. But I think it’s worth it.
The email discussion has gone around long enough. Let’s discuss a concrete proposal. For the following functions or methods, I removed `foo` (that caused task failure) and renamed `foo_opt` (that returns `Option`) to just `foo`.
Vector methods:
* `get_opt` (rename only, `get` did not exist as it would have been just `[]`)
* `head_opt`
* `last_opt`
* `pop_opt`
* `shift_opt`
* `remove_opt`
`std::path::BytesContainer` method:
* `container_as_str_opt`
`std::str` functions:
* `from_utf8_opt`
* `from_utf8_owned_opt` (also remove the now unused `not_utf8` condition)
Is there something else that should recieve the same treatement?
I did not rename `recv_opt` on channels based on @brson’s [feedback](https://mail.mozilla.org/pipermail/rust-dev/2013-December/007270.html).
Feel free to pick only some of these commits.
|
|
from_utf8_owned() behavior
|
|
behavior
|
|
To build for the cortex-M series ARM processors LLC needs to be told to build for the thumb instruction set. There are two ways to do this, either with the triple "thumb\*-\*-\*" or with -march=thumb (which just overrides the triple anyway). I chose the first way.
The following will fail because the local cc doesn't know what to do with -mthumb.
````
rustc test.rs --lib --target thumb-linux-eab
error: linking with `cc` failed: exit code: 1
note: cc: error: unrecognized command line option ‘-mthumb’
````
Changing the linker works as expected.
````
rustc test.rs --lib --target thumb-linux-eabi --linker arm-none-eabi-gcc
````
Ideally I'd have the triple thumb-none-eabi, but adding a new OS looks like much more work (and I'm not familiar enough with what it does to know if it is needed).
|
|
|
|
* borrowck_note_pure - unused
* borrowck_note_loan - unused
* no_debug_borrows - unused
* lint_llvm - equivalent to -Z no-prepopulate-passes + --llvm-passes lint
|
|
|
|
|
|
Apparently this isn't necessary, and it's just causing problems.
Closes #11162
|
|
|
|
driver::session::crate_metadata is unused; removed.
|
|
Apparently this isn't necessary, and it's just causing problems.
Closes #11162
|
|
|
|
drop_glue).
|
|
|
|
|
|
...stlib. Fixes #3319
|
|
|
|
|
|
|
|
|
|
rustlib. Fixes #3319
|
|
|
|
Right now if you have concurrent builds of two libraries in the same directory
(such as rustc's bootstrapping process), it's possible that two libraries will
stomp over each others' metadata, producing corrupt rlibs.
By placing the metadata file in a tempdir we're guranteed to not conflict with
ay other builds happening concurrently. Normally this isn't a problem because
output filenames are scoped to the name of the crate, but metadata is special in
that it has the same name across all crates.
|
|
Rationale can be found in the first commit, but this is basically the same thing as `pthread_once`
|
|
|
|
|
|
Closes #11154
|
|
Closes #11154
|
|
|
|
Right now if you have concurrent builds of two libraries in the same directory
(such as rustc's bootstrapping process), it's possible that two libraries will
stomp over each others' metadata, producing corrupt rlibs.
By placing the metadata file in a tempdir we're guranteed to not conflict with
ay other builds happening concurrently. Normally this isn't a problem because
output filenames are scoped to the name of the crate, but metadata is special in
that it has the same name across all crates.
|
|
|
|
|
|
This also appears to fix a race in LLVM that was causing a deadlock on the bots
during the doc-test tests (where we use rustc in parallel).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
