under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).
but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).
this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.
Quite a bit of cruft in the valgrind suppressions. I started from a clean slate and found a few unique failures; this commit also moves the tests "fixed" by these suppressions into run-pass-valgrind.
Hi Rustaceans!
This is the second take on running latest rustfmt on librustc_front!
This is the same in https://github.com/rust-lang/rust/pull/29075 but cleaned. All fixups have been applied.
//cc @nrc
This commit replaces the in-tree liblibc with the [external clone](https://github.com/rust-lang-nursery/libc) which has no evolved beyond the in-tree version in light of its [recent redesign](https://github.com/rust-lang/rfcs/pull/1291).
The primary changes here are:
* `src/liblibc/lib.rs` was deleted
* `src/liblibc` is now a submodule pointing at the external repository
* `src/libstd/sys/unix/{c.rs,sync.rs}` were both deleted having all bindings folded into the external liblibc.
* Many ad-hoc `extern` blocks in the standard library were removed in favor of bindings now being in the external liblibc.
* Many functions/types were added to `src/libstd/sys/windows/c.rs`, and the scattered definitions throughout the standard library were consolidated here.
At the API level this commit is **not a breaking change**, although it is only very lightly tested on the *BSD variants and is probably going to break almost all of their builds! Follow-up commits to liblibc should in theory be all that's necessary to get the build working on the *BSDs again.
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
The struct_variant feature was accepted and is no longer feature gated.
See #19122, #19124
§6.1.6 Enumerations shows an example of a struct-like enum variant.
This standardises the current behavior to match `enum` variants, hopefully leading to less warning spam for users!
For example the code below will have 2 warnings (for `Foo` and `Bar`) rather than 7:
```rust
enum Foo {
A,
B { a: String, b: isize },
C
}
struct Bar {
a: i32,
b: String,
c: ()
}
fn main() {
println!("Hi")
}
```
http://is.gd/zAztKW
In src/doc/trpl/error-handling.md, in this section:
It mentions three steps, to "convert this to proper error handling", the last one being:
3. Handle the error in main.
However, it is not shown. This pull request adds a code example showing how `main`'s call to `search` should use case analysis. I am still very much new to learning Rust, so this may not be idiomatic. Happy to make changes with guidance.
The struct_variant feature was accepted and is no longer feature gated.
See #19122, #19124
§6.1.6 Enumerations shows an example of a struct-like enum variant.
Resolves #29672. This happened because rust runtime startup objects, rsbegin.o and rsend.o, were not included in the target libraries package for -windows-gnu.
r? @alexcrichton
The `enable-nonzeroing-move-hints` flag name was too long and caused misalignment of the help text.
Now calculating the needed padding dynamically from the available flags instead.
Allow the changing of `target_family` through flexible configuration. The whole computing world isn't just a binary of *nix and Windows! Makes porting `libstd` and co to new platforms a lot less painful.
* Store the native representation directly in the `ExitStatus` structure instead
of a "parsed version" (mostly for Unix).
* On Windows, be more robust against processes exiting with the status of 259.
Unfortunately this exit code corresponds to `STILL_ACTIVE`, causing libstd to
think the process was still alive, causing an infinite loop. Instead the loop
is removed altogether and `WaitForSingleObject` is used to wait for the
process to exit.
