r? @steveklabnik
This completely abdicates any responsibility to explain what Rust is, instead linking to the website.
My main motivation is that I am still not happy with it, and every time I try to fix it I just write a slightly longer sales pitch than what's on the website.
One thing this paragraph could do is direct people to more information about what is in the repo, or more technical information about the implementation.
Since commit 46068c9da, call to `reserve()` on empty vec allocates
exactly requested capacity, so unroll of first iteration may help only
with branch prediction.
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 comparison of IP addresses should happen not always in network endianness
but rather in the host endianness format, so be sure to convert to that before
comparing addresses.
There are still locations where the endianness will factor into visible
properties, such as the hash, but these are not important to be independent of
the endianness in play (as hash values are pretty undefined anyway.
Closes#29691
This commit adds issue numbers to the vast majority of active feature
gates. The few that are left without issues are rustc/runtime-internal
features that are essentially private APIs.
Closes#28244
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.
